Your Company’s Next Insider Threat Won’t Be a Person—It’ll Be the ‘Helpful’ AI Agent You Gave Gmail + DocuSign Access
When an agent can ingest untrusted email and execute high-trust actions like routing signatures, the question shifts from who has access to what can act as you—and what can steer it.
By TheMurrow Editorial
March 1, 2026
Key Points
- 1Reframe insider risk: AI agents with Gmail + DocuSign access can ingest untrusted inputs and execute high-trust actions under your authority.
- 2Treat OAuth consent as a credential event: fake apps, device-code phishing, and agent lures can grant persistent access without passwords.
- 3Constrain and instrument agents: least privilege, deterministic routing, human approvals for state changes, and audit trails to detect hijacking and exfiltration.
Most security teams learned to fear the “insider threat” as a person: a disgruntled employee, a careless contractor, an executive who clicks the wrong link. That model still matters. Yet the more consequential shift in 2025 and beyond is quieter: organizations are delegating sensitive work to software that can read, decide, and act.
Give an AI agent access to Gmail and DocuSign—two everyday tools in modern business—and you’ve created something new: a system that ingests untrusted messages from the outside world and can execute high-trust actions inside your company. It can summarize a contract. It can route it for signature. It can send the follow-up email that closes the loop.
The difference isn’t philosophical. It’s operational. When the “actor” is a machine operating under delegated authority—OAuth tokens, connectors, API keys—the core security question changes from who has access to what can act on your behalf, and what can steer it.
“The insider threat isn’t always an insider anymore. It can be a delegated machine identity with your permissions.”
— — TheMurrow Editorial
The insider threat model breaks when the insider is software
Classic insider-risk programs assume a human misuses legitimate access, either maliciously or through negligence. Agentic AI reshapes that picture because the system executing actions may be software operating under a user’s delegated authority—often triggered by natural-language instructions and fed by content the organization does not control.
NIST has explicitly treated “AI agent hijacking” as a security risk category. In a January 2025 technical blog, NIST described the pattern plainly: attackers embed malicious instructions in content an agent ingests—an email, a file, a webpage—causing the agent to take unintended actions. The familiar term is indirect prompt injection, but the security impact is closer to workflow sabotage than to a bad chatbot answer. The system is not just responding; it’s doing.
NIST has explicitly treated “AI agent hijacking” as a security risk category. In a January 2025 technical blog, NIST described the pattern plainly: attackers embed malicious instructions in content an agent ingests—an email, a file, a webpage—causing the agent to take unintended actions. The familiar term is indirect prompt injection, but the security impact is closer to workflow sabotage than to a bad chatbot answer. The system is not just responding; it’s doing.
Agents become a distinct governance surface
Microsoft has also elevated “agents” into a distinct governance surface. In February 2026, Microsoft’s security guidance for Copilot Studio laid out concrete risk patterns that security teams can actually hunt and mitigate: email-based data exfiltration, overbroad sharing, unauthenticated agents, and agents that run with maker/author credentials—a form of privilege inheritance that can surprise even careful builders.
The debate is no longer whether AI can “leak data.” The question is how easily ordinary business workflows become high-impact execution paths: triage email → draft reply → send; read contract → route for signature; search files → summarize → share. Each arrow is a decision point an attacker can try to steer.
The debate is no longer whether AI can “leak data.” The question is how easily ordinary business workflows become high-impact execution paths: triage email → draft reply → send; read contract → route for signature; search files → summarize → share. Each arrow is a decision point an attacker can try to steer.
Delegated authority changes the accountability chain
A human insider is visible: HR knows who they are, and security can investigate intent. A machine identity operating through delegated access is harder to reason about. The authorization looks legitimate. The logs may show “user consented.” The actions may be perfectly formatted, timely, and plausible.
That creates a new governance requirement: not just “least privilege,” but least privilege for automations that can be redirected by content.
That creates a new governance requirement: not just “least privilege,” but least privilege for automations that can be redirected by content.
Key Insight
When the actor is a machine identity using delegated authority (OAuth tokens, connectors, API keys), the security question becomes: what can act as you—and what can steer it?
OAuth, connectors, and why “consent is the new password”
Agents typically don’t need your password to become dangerous. They need your consent.
Modern workplace agents operate through OAuth authorization and connectors to services like Gmail/Google Workspace, Microsoft 365, Slack/Teams, CRMs, and e-signature platforms. Once authorized, an agent can use tokens to read email, search documents, post messages, or kick off workflows—often without re-prompting the user for each step.
Proofpoint documented an ongoing campaign observed from early 2025 onward abusing fake OAuth apps and redirects as a lure. Some impersonated tools including DocuSign, among other recognizable brands. The tactic illustrates a critical point: attackers don’t always need to break authentication; they can persuade people to grant access through flows that look routine.
A separate thread underscores how “legitimate login” can still mean “illegitimate access.” Security reporting has warned about a surge in OAuth device-code phishing leading to Microsoft 365 account takeovers, where victims authenticate on legitimate Microsoft domains and still end up granting attackers access. The user experience feels safe because the domain is real. The outcome is not.
Modern workplace agents operate through OAuth authorization and connectors to services like Gmail/Google Workspace, Microsoft 365, Slack/Teams, CRMs, and e-signature platforms. Once authorized, an agent can use tokens to read email, search documents, post messages, or kick off workflows—often without re-prompting the user for each step.
Proofpoint documented an ongoing campaign observed from early 2025 onward abusing fake OAuth apps and redirects as a lure. Some impersonated tools including DocuSign, among other recognizable brands. The tactic illustrates a critical point: attackers don’t always need to break authentication; they can persuade people to grant access through flows that look routine.
A separate thread underscores how “legitimate login” can still mean “illegitimate access.” Security reporting has warned about a surge in OAuth device-code phishing leading to Microsoft 365 account takeovers, where victims authenticate on legitimate Microsoft domains and still end up granting attackers access. The user experience feels safe because the domain is real. The outcome is not.
“When access is granted by consent screens, the most dangerous click may be the one that looks the most official.”
— — TheMurrow Editorial
Agents add a new lure: “log in so I can help you”
Researchers have also highlighted an agent-flavored variant. Datadog described “CoPhish,” in which maliciously designed Microsoft Copilot Studio agents trick users into clicking a login/consent flow to steal OAuth tokens. Microsoft characterized the technique as social engineering and indicated planned mitigations.
The significance isn’t the brand names. It’s the pattern: when an agent is presented as helpful, users expect it to ask for access. That expectation lowers defenses around permission prompts—especially when the organization is actively encouraging employees to adopt agents for productivity.
Practical implication for readers: treat OAuth consent dialogs as credential events. If your policy treats passwords and MFA with seriousness but treats connector consent as routine, attackers will choose the easier path.
The significance isn’t the brand names. It’s the pattern: when an agent is presented as helpful, users expect it to ask for access. That expectation lowers defenses around permission prompts—especially when the organization is actively encouraging employees to adopt agents for productivity.
Practical implication for readers: treat OAuth consent dialogs as credential events. If your policy treats passwords and MFA with seriousness but treats connector consent as routine, attackers will choose the easier path.
Editor’s Note
Practical implication for readers: treat OAuth consent dialogs as credential events. If connector consent feels “routine,” attackers will choose it over breaking MFA.
Prompt injection becomes operational once tools are connected
Prompt injection used to sound like a parlor trick: someone hides “ignore previous instructions” in a block of text and the model behaves oddly. Tool access changes the stakes. Now the same trick can move from the model’s output into the organization’s systems.
NIST’s agent hijacking description is direct: malicious instructions embedded in normal data—email, file content, web pages—can cause an agent to take harmful actions while performing a legitimate task. The agent is not “compromised” in the traditional sense; it is misled while acting within its granted permissions.
Microsoft’s Copilot Studio guidance calls out email-based exfiltration as a specific risk, especially when recipients or content are dynamically determined at runtime—when an orchestrator decides where information goes based on what it sees. That is exactly the pattern agents are designed for: interpret context, decide next steps, take action. It is also exactly what attackers want to influence.
NIST’s agent hijacking description is direct: malicious instructions embedded in normal data—email, file content, web pages—can cause an agent to take harmful actions while performing a legitimate task. The agent is not “compromised” in the traditional sense; it is misled while acting within its granted permissions.
Microsoft’s Copilot Studio guidance calls out email-based exfiltration as a specific risk, especially when recipients or content are dynamically determined at runtime—when an orchestrator decides where information goes based on what it sees. That is exactly the pattern agents are designed for: interpret context, decide next steps, take action. It is also exactly what attackers want to influence.
Standards and ecosystems can widen the blast radius
Tool integration standards also change the risk profile. A 2026 academic paper analyzing the Model Context Protocol (MCP) argued that protocol design can amplify prompt-injection risks, including issues like capability claims and trust propagation across multi-server setups. The authors reported higher attack success rates in experiments and proposed protocol-level mitigations—an indicator that the research community sees integration plumbing as a security boundary, not a neutral conduit.
Meanwhile, real-world security reporting continues to show how young these ecosystems are. Check Point reported critical vulnerabilities affecting Anthropic’s Claude Code and MCP-related components that could enable code execution or secret theft (since patched). The details matter less than the broader lesson: when agents are wired into many tools, both social engineering and software vulnerabilities can turn into business-impact incidents.
Meanwhile, real-world security reporting continues to show how young these ecosystems are. Check Point reported critical vulnerabilities affecting Anthropic’s Claude Code and MCP-related components that could enable code execution or secret theft (since patched). The details matter less than the broader lesson: when agents are wired into many tools, both social engineering and software vulnerabilities can turn into business-impact incidents.
“Tool access turns prompt injection from a weird output into a real action.”
— — TheMurrow Editorial
Gmail is the universal ingestion channel—attackers know it
Email remains the most reliable delivery mechanism for attackers because it sits at the boundary between the outside world and internal work. Invoices arrive by email. Contract redlines arrive by email. “Can you sign this today?” arrives by email. That makes Gmail (and email generally) the natural place to plug in agents meant to triage, summarize, and respond.
If an agent can read, search, and send email, a successful hijack can enable:
- Exfiltration: forwarding sensitive content or summaries outside the organization
- Silent lateral movement: finding internal threads, then using email-based password resets or approval chains
- Business email compromise acceleration: drafting and sending plausible messages at scale, matching tone and context
Microsoft’s security guidance points out a subtle but crucial risk: exfiltration becomes more plausible when an agent decides recipients at runtime. A rule-based system that only sends to a fixed list is easier to constrain. An agent that “figures out who to send it to” is more useful—and harder to secure.
If an agent can read, search, and send email, a successful hijack can enable:
- Exfiltration: forwarding sensitive content or summaries outside the organization
- Silent lateral movement: finding internal threads, then using email-based password resets or approval chains
- Business email compromise acceleration: drafting and sending plausible messages at scale, matching tone and context
Microsoft’s security guidance points out a subtle but crucial risk: exfiltration becomes more plausible when an agent decides recipients at runtime. A rule-based system that only sends to a fixed list is easier to constrain. An agent that “figures out who to send it to” is more useful—and harder to secure.
Email is also the easiest place to hide instructions
NIST’s framing of agent hijacking emphasizes that malicious instructions can be embedded in normal content. Email is ideal for that because it can carry instructions in:
- Body text (including “helpful” step-by-step guidance)
- Attached documents the agent might summarize
- Links to web pages the agent might consult
The end-user may see an ordinary request. The agent may see a set of “instructions” that look like task-related context. Without robust safeguards, the boundary between “content to read” and “instructions to follow” becomes porous.
For leaders considering Gmail-connected agents, the decision is not “email is risky.” Email has always been risky. The decision is whether you are comfortable turning email from a communication channel into an execution trigger.
- Body text (including “helpful” step-by-step guidance)
- Attached documents the agent might summarize
- Links to web pages the agent might consult
The end-user may see an ordinary request. The agent may see a set of “instructions” that look like task-related context. Without robust safeguards, the boundary between “content to read” and “instructions to follow” becomes porous.
For leaders considering Gmail-connected agents, the decision is not “email is risky.” Email has always been risky. The decision is whether you are comfortable turning email from a communication channel into an execution trigger.
Early 2025 onward
Proofpoint documented ongoing campaigns abusing fake OAuth apps and redirects, sometimes impersonating recognizable brands including DocuSign.
DocuSign is a high-trust execution channel, not just another app
If email is where instructions arrive, DocuSign is where actions become binding.
E-signature workflows carry an aura of legitimacy. Recipients expect time pressure. The brand itself often lowers suspicion. Proofpoint’s reporting that some fake OAuth app impersonations included DocuSign signals why attackers keep circling the space: the combination of trust and urgency is hard to beat.
Now add an agent. A well-integrated agent can:
- Pull an agreement from email or a shared drive
- Summarize key terms
- Route to the right signer
- Send reminders and follow-ups
- Record completion and notify stakeholders
Each step saves time. Each step also becomes a potential lever for misdirection if an agent is steered by malicious content or if an attacker obtains delegated access through OAuth token theft.
E-signature workflows carry an aura of legitimacy. Recipients expect time pressure. The brand itself often lowers suspicion. Proofpoint’s reporting that some fake OAuth app impersonations included DocuSign signals why attackers keep circling the space: the combination of trust and urgency is hard to beat.
Now add an agent. A well-integrated agent can:
- Pull an agreement from email or a shared drive
- Summarize key terms
- Route to the right signer
- Send reminders and follow-ups
- Record completion and notify stakeholders
Each step saves time. Each step also becomes a potential lever for misdirection if an agent is steered by malicious content or if an attacker obtains delegated access through OAuth token theft.
The combustible combination: Gmail + DocuSign
Individually, Gmail access is powerful. DocuSign access is consequential. Together, they form a pipeline: inbound request → document handling → signature execution → outbound confirmation. That is a complete business transaction loop.
A plausible failure mode, consistent with NIST’s hijacking pattern and Microsoft’s exfiltration warnings, looks like this:
1. An attacker sends a realistic email request containing embedded instructions aimed at an agent (or a document that contains them).
2. The agent, operating under delegated access, reads the content and “helpfully” follows the malicious directive.
3. The agent forwards sensitive material externally, or routes a document to an unintended recipient, or initiates an approval/signature workflow that should have required human verification.
None of that requires the model to be “evil.” It requires only that the agent is permitted to act, and that it cannot reliably distinguish untrusted content from trusted instructions.
A plausible failure mode, consistent with NIST’s hijacking pattern and Microsoft’s exfiltration warnings, looks like this:
1. An attacker sends a realistic email request containing embedded instructions aimed at an agent (or a document that contains them).
2. The agent, operating under delegated access, reads the content and “helpfully” follows the malicious directive.
3. The agent forwards sensitive material externally, or routes a document to an unintended recipient, or initiates an approval/signature workflow that should have required human verification.
None of that requires the model to be “evil.” It requires only that the agent is permitted to act, and that it cannot reliably distinguish untrusted content from trusted instructions.
A plausible Gmail + DocuSign agent failure mode
- 1.An attacker sends a realistic email request containing embedded instructions aimed at an agent (or a document that contains them).
- 2.The agent, operating under delegated access, reads the content and “helpfully” follows the malicious directive.
- 3.The agent forwards sensitive material externally, routes a document to an unintended recipient, or initiates an approval/signature workflow that should have required human verification.
The vendor view: governance is finally catching up—slowly
Security teams often complain that AI risks are described in vague, futuristic language. The most useful recent developments are the opposite: vendors and standards bodies describing concrete failure patterns that map to controls.
NIST’s January 2025 work on strengthening evaluations of AI agent hijacking is a signal that the problem is being formalized into testable categories. Formalization matters because it enables benchmarks, procurement requirements, and audit questions that go beyond “we use AI responsibly.”
Microsoft’s February 2026 Copilot Studio “top risks” guidance is similarly practical. Among other patterns, Microsoft highlighted:
- Email-based data exfiltration
- Overbroad sharing
- Unauthenticated agents
- Agents running with maker/author credentials
Those risks read like the early days of cloud IAM—when companies discovered that “it works” is not the same as “it’s governed.”
NIST’s January 2025 work on strengthening evaluations of AI agent hijacking is a signal that the problem is being formalized into testable categories. Formalization matters because it enables benchmarks, procurement requirements, and audit questions that go beyond “we use AI responsibly.”
Microsoft’s February 2026 Copilot Studio “top risks” guidance is similarly practical. Among other patterns, Microsoft highlighted:
- Email-based data exfiltration
- Overbroad sharing
- Unauthenticated agents
- Agents running with maker/author credentials
Those risks read like the early days of cloud IAM—when companies discovered that “it works” is not the same as “it’s governed.”
A fair counterpoint: productivity is real, and so are mitigations
Skeptics sometimes frame all agentic AI as inherently unsafe. That position doesn’t fit the evidence. The evidence says the risks are specific and, in many cases, controllable—if leaders treat agents as identity-bearing systems with auditable permissions and constrained capabilities.
The more balanced view: agents are neither toys nor autonomous employees. They are automation engines with language interfaces. When organizations apply the same rigor they apply to privileged access management—scoping, logging, review, revocation—agents can deliver value without becoming silent super-users.
The more balanced view: agents are neither toys nor autonomous employees. They are automation engines with language interfaces. When organizations apply the same rigor they apply to privileged access management—scoping, logging, review, revocation—agents can deliver value without becoming silent super-users.
Jan 2025
NIST described “AI agent hijacking” as attackers embedding malicious instructions in agent-ingested content to trigger unintended actions.
Feb 2026
Microsoft’s Copilot Studio guidance elevated concrete agent risks: email-based exfiltration, overbroad sharing, unauthenticated agents, and maker/author credential inheritance.
Practical safeguards that actually match the threat
Security advice for AI often collapses into platitudes: “add guardrails,” “train employees,” “monitor outputs.” The research points to sharper, more operational moves—especially when Gmail and DocuSign are in the mix.
1) Treat OAuth consent like a credential event
Proofpoint’s early-2025 observations of fake OAuth apps, plus device-code phishing reports tied to real vendor domains, make one message unavoidable: authorization flows are an attack surface.
Practical steps:
- Require admin approval or vetted allowlists for OAuth apps and connectors where possible.
- Review granted scopes regularly; remove apps with broad permissions.
- Educate users that a “real” domain does not guarantee a “safe” consent request.
Practical steps:
- Require admin approval or vetted allowlists for OAuth apps and connectors where possible.
- Review granted scopes regularly; remove apps with broad permissions.
- Educate users that a “real” domain does not guarantee a “safe” consent request.
2) Minimize agent privileges—and avoid privilege inheritance surprises
Microsoft’s warning about agents running with maker/author credentials is a reminder that builders can unintentionally grant sweeping power. Prefer narrowly scoped service identities where available, and avoid designs where an agent silently inherits a human’s full access.
Practical steps:
- Limit email actions: reading may be necessary; sending externally may not be.
- Limit DocuSign actions: prepare drafts, but require human confirmation to send or finalize.
- Require explicit approval for any action that changes state (send, share, sign, pay).
Practical steps:
- Limit email actions: reading may be necessary; sending externally may not be.
- Limit DocuSign actions: prepare drafts, but require human confirmation to send or finalize.
- Require explicit approval for any action that changes state (send, share, sign, pay).
3) Assume untrusted content will try to steer the agent
NIST’s hijacking framing starts with content as the delivery vehicle. Put defensive boundaries where content crosses into instruction.
Practical steps:
- Separate “data” from “instructions” in agent design; don’t let arbitrary email text become directives.
- Restrict which sources an agent can browse or ingest for high-impact workflows.
- Prefer deterministic routing for sensitive recipients; avoid runtime “decide who gets this” behavior for confidential material, echoing Microsoft’s exfiltration cautions.
Practical steps:
- Separate “data” from “instructions” in agent design; don’t let arbitrary email text become directives.
- Restrict which sources an agent can browse or ingest for high-impact workflows.
- Prefer deterministic routing for sensitive recipients; avoid runtime “decide who gets this” behavior for confidential material, echoing Microsoft’s exfiltration cautions.
4) Instrument agents like privileged systems
Agent activity should be loggable and reviewable: what it read, what tools it invoked, what it sent, and to whom. When incidents happen, the difference between a contained event and a catastrophe is often visibility.
Practical steps:
- Maintain audit trails for agent tool calls and outbound communications.
- Set alerting on unusual recipient domains, unusual signing patterns, or new OAuth grants.
- Periodically test for hijacking attempts using internal red-team exercises aligned with NIST’s agent hijacking concept.
Practical steps:
- Maintain audit trails for agent tool calls and outbound communications.
- Set alerting on unusual recipient domains, unusual signing patterns, or new OAuth grants.
- Periodically test for hijacking attempts using internal red-team exercises aligned with NIST’s agent hijacking concept.
“If an agent can send an email or route a signature, treat it like a privileged account—because it is.”
— — TheMurrow Editorial
Practical steps (operational controls)
- ✓Require admin approval or vetted allowlists for OAuth apps and connectors where possible.
- ✓Review granted scopes regularly; remove apps with broad permissions.
- ✓Educate users that a “real” domain does not guarantee a “safe” consent request.
- ✓Limit email actions: reading may be necessary; sending externally may not be.
- ✓Limit DocuSign actions: prepare drafts, but require human confirmation to send or finalize.
- ✓Require explicit approval for any action that changes state (send, share, sign, pay).
- ✓Separate “data” from “instructions” in agent design; don’t let arbitrary email text become directives.
- ✓Restrict which sources an agent can browse or ingest for high-impact workflows.
- ✓Prefer deterministic routing for sensitive recipients; avoid runtime “decide who gets this” behavior.
- ✓Maintain audit trails for agent tool calls and outbound communications.
- ✓Set alerting on unusual recipient domains, unusual signing patterns, or new OAuth grants.
- ✓Periodically test for hijacking attempts using internal red-team exercises aligned with NIST’s concept.
The question leaders should ask before connecting agents to Gmail and DocuSign
The most revealing question is not “Is the model safe?” Models matter. Yet the research and guidance point elsewhere: the center of gravity is delegated machine access plus untrusted inputs plus high-trust actions.
If you connect an agent to Gmail, you are giving it a firehose of external content designed to trigger action. If you connect it to DocuSign, you are giving it a lever that can finalize agreements and move money-adjacent processes forward. Neither is reckless by default. Both demand a security posture that treats agents as a new class of operator.
NIST is building evaluation approaches for hijacking because the pattern is real and repeatable. Microsoft is cataloging agent risks because customers are deploying them at scale. Proofpoint is tracking OAuth abuse because attackers have already learned the value of consent theft. Academic and industry research on MCP and integration vulnerabilities adds a final reminder: the ecosystem is moving fast, and plumbing mistakes can become security incidents.
The old insider-threat story was about trust misplaced in people. The new story is about trust delegated to systems that can be steered by the outside world. Organizations that recognize that distinction early—before the first “helpful” agent forwards the wrong thread or routes the wrong document—will keep the productivity gains and avoid the painful lessons.
If you connect an agent to Gmail, you are giving it a firehose of external content designed to trigger action. If you connect it to DocuSign, you are giving it a lever that can finalize agreements and move money-adjacent processes forward. Neither is reckless by default. Both demand a security posture that treats agents as a new class of operator.
NIST is building evaluation approaches for hijacking because the pattern is real and repeatable. Microsoft is cataloging agent risks because customers are deploying them at scale. Proofpoint is tracking OAuth abuse because attackers have already learned the value of consent theft. Academic and industry research on MCP and integration vulnerabilities adds a final reminder: the ecosystem is moving fast, and plumbing mistakes can become security incidents.
The old insider-threat story was about trust misplaced in people. The new story is about trust delegated to systems that can be steered by the outside world. Organizations that recognize that distinction early—before the first “helpful” agent forwards the wrong thread or routes the wrong document—will keep the productivity gains and avoid the painful lessons.
T
About the Author
TheMurrow Editorial is a writer for TheMurrow covering trends.
Frequently Asked Questions
What is “AI agent hijacking,” and how is it different from prompt injection?
NIST describes AI agent hijacking as attackers embedding malicious instructions in content an agent ingests—like an email, document, or webpage—so the agent takes unintended actions. Traditional prompt injection often focuses on manipulating model output. Hijacking becomes more serious when the agent has tool access (email, files, e-sign workflows) and can execute actions using delegated permissions.
Why does OAuth make agent security harder?
OAuth shifts risk from stolen passwords to stolen—or tricked—consent. Proofpoint has documented campaigns since early 2025 using fake OAuth apps and redirects, sometimes impersonating brands like DocuSign. Separate reporting on device-code phishing shows victims can authenticate on legitimate vendor domains yet still grant attackers access. When agents rely on OAuth tokens, compromised consent can translate into silent, persistent access.
Are Gmail-connected agents inherently unsafe?
Not inherently. Gmail is risky because it is a high-volume untrusted input channel. NIST’s hijacking model explicitly relies on agents ingesting normal content that contains malicious instructions. If an agent can read and send email, a successful hijack can enable exfiltration or credible internal fraud. Safety depends on least-privilege scopes, strict controls on outbound actions, and logging/monitoring.
Why is DocuSign access especially sensitive for an agent?
DocuSign-style e-sign tools are execution channels: they move agreements through trusted workflows and are designed to be acted on quickly. Proofpoint’s observation of OAuth impersonation campaigns including DocuSign underscores attacker interest in the trust surrounding signature flows. If an agent can route or send signature requests, errors or manipulation can produce binding outcomes, not just leaked text.
What does Microsoft recommend watching for with workplace agents?
Microsoft’s Copilot Studio security guidance (Feb 2026) lists concrete agent risks including email-based data exfiltration, overbroad sharing, unauthenticated agents, and agents that run with maker/author credentials (privilege inheritance). The practical takeaway: treat agents as a governance surface, with deliberate identity, permissions, and monitoring—not as ordinary apps.
How do standards like MCP affect risk?
The Model Context Protocol (MCP) expands how agents connect to tools and external systems. A 2026 academic analysis argued protocol design can amplify prompt-injection risks, including trust propagation across multi-server setups, and reported higher attack success rates in experiments. Security teams should evaluate not only the agent but the integration protocol, server trust assumptions, and how capabilities are represented and constrained.
