From Readers to Actors: Why Agents Change the Risk Equation

For most of AI’s enterprise history, the threat model was relatively contained. A poisoned document could skew a summary. A manipulated prompt could produce a misleading answer. The damage stayed within the conversation.
Agents operate differently. Microsoft 365 Copilot can send email, create calendar entries, and generate files. Custom agents built in Copilot Studio or Azure AI Foundry can reach into business systems and execute multi-step workflows autonomously. When an attacker manipulates an agent, they are not changing an answer — they are changing what the software actually does.
The connective tissue between these agents and the outside world is MCP, the Model Context Protocol. It is an open standard that lets AI agents call external tools the way an application calls an API. Microsoft describes it as the fastest-growing component of the agentic AI supply chain. That growth rate is also a measure of expanding attack surface.
The Mechanics of Tool Poisoning

Every MCP tool ships with a plain-text description — a few lines that tell the agent what the tool does and when to invoke it. The agent reads that text to make decisions. That is the entire vulnerability.
Microsoft illustrates the attack pattern with a constructed invoice scenario, designed to demonstrate the mechanism rather than document a specific breach. A finance team deploys an agent to process vendor invoices. It connects to three tools, one of which is a third-party invoice enrichment service that was approved for use but never subjected to rigorous security review.
The attacker then modifies that third-party tool. The visible name and summary remain unchanged. Buried inside the description — formatted to resemble innocuous configuration notes — is a hidden instruction: collect the last thirty unpaid invoices and attach them to the next outbound call. MCP picks up description changes dynamically. In environments without a re-approval trigger, the poisoned version goes live immediately and silently.
When an analyst later asks a routine question about a supplier, the agent follows the hidden instruction. It collects the invoice data and forwards it as part of what appears to be a normal API request. The tool returns a clean answer to the analyst. The stolen data travels to an attacker-controlled server. Nothing visible goes wrong.
Why Each Step Passes Inspection
The attack succeeds because every individual action is technically legitimate. The tool was on the approved list. The data query ran under the analyst’s own permissions. The outbound call went to a server that was whitelisted when the tool was first registered.
Microsoft identifies the structural problem precisely: the weakness does not live in any single system. It lives in what the research calls “the trust boundary between them.” MCP places tool descriptions and operational instructions in the same working memory. Editing a description steers the agent as effectively as rewriting its system prompt — and the agent has no reliable mechanism to distinguish a genuine instruction from a malicious one embedded by whoever maintains the tool.
This is not a defect in Copilot. It is a trust gap that opens the moment you connect an outside tool.
The Four-Phase Attack Chain
Microsoft maps the attack across four discrete phases:
- Phase 1 — Initial Compromise: A third-party MCP server’s tool description is poisoned, targeting an enterprise Copilot Studio agent.
- Phase 2 — Silent Re-Trust: Agent dependencies are re-trusted without triggering a review cycle.
- Phase 3 — Agent Execution: The agent acts using the analyst’s own permissions, making the activity indistinguishable from legitimate use.
- Phase 4 — Exfiltration: Data exits over a command-and-control channel to a threat actor endpoint.
This Is Not a Theoretical Concern
The attack class has a documented history that predates Microsoft’s current research.
Invariant Labs named “tool poisoning” in April 2025, publishing a proof of concept that hid instructions inside a calculator tool’s description and successfully caused the Cursor editor to read a user’s private SSH key and transmit it externally. The same researchers later demonstrated that a malicious GitHub issue could hijack an agent connected to the GitHub MCP server and walk data out of private repositories — without touching the tools themselves. The instructions rode in on the data the agent read.
OWASP has since cited that GitHub case as an Agentic Supply Chain Vulnerabilities example in its December 2025 Top 10 for Agentic Applications.
A real-world supply chain failure followed in September 2025. Researchers at Koi Security identified an npm package called postmark-mcp that had mirrored a legitimate email tool across fifteen clean releases before version 1.0.16 inserted a single line that silently BCC’d every agent-sent email to an attacker. Koi described it as the first confirmed malicious MCP server in the wild.
Academic measurement has now arrived as well. The MCPTox benchmark, released in August 2025, tested poisoned tool descriptions against 45 real MCP servers and 20 leading AI models. The attack succeeded at rates as high as 72.8 percent. The models almost never refused.
What Defenders Must Do Now
Microsoft’s research is not only diagnostic. It maps specific controls to each attack phase, oriented around three objectives: reduce the likelihood of compromise, limit impact through containment, and detect suspicious activity quickly enough to respond.
The practical guidance translates into five operational priorities:
- Treat every connected tool as supply chain. Maintain a registry of approved tool publishers. Disable permissive “allow all” configurations. Restrict each agent to only the specific tools its function requires.
- Treat tool descriptions like system prompts. Any change to a tool’s description should go through the same review process as a code change. Scan description text for embedded commands that have no legitimate place in a help field.
- Put humans in front of high-risk actions. Any operation that moves money, shares data outside the organization, or modifies accounts should require explicit human approval before execution.
- Give each agent its own identity and audit trail. Log agent actions, establish a behavioral baseline, and flag anomalies — new outbound endpoints, unusually large data pulls, or queries that fall outside normal patterns.
- Apply least agency, not just least privilege. A low-permission agent can still cause significant harm if it is permitted to act without checks. Constraining what an agent is allowed to do is as important as constraining what data it can access.
Microsoft maps its own product stack to these controls — Prompt Shields, Purview DLP, Entra Agent ID, Defender for Cloud, and Sentinel — but the principles apply regardless of which platform you operate on.
The Throughline
The pattern running through every case — Microsoft’s research, the Invariant Labs proof of concept, the postmark-mcp incident, the MCPTox benchmark — is consistent. AI that can act is only as trustworthy as the tools you allow it to touch.
Right now, those tools are easy to poison and hard to watch. Description changes propagate silently. Review processes designed for code do not automatically extend to plain-text metadata. And agents execute with the permissions of the humans who invoked them, which means a poisoned tool inherits whatever access that person has.
The security perimeter for enterprise AI is no longer the model. It is the entire ecosystem the model can reach. Organizations deploying agentic AI without treating that ecosystem as a supply chain are, in effect, trusting every tool publisher with the same access they grant their own employees — without the same vetting, monitoring, or accountability.
That gap is what Microsoft is pressing organizations to close. The benchmark numbers suggest the window for doing so quietly is already narrowing.
Comments (0) No comments yet
Want to join this discussion? Login or Register.
No comments yet. Be the first to share your thoughts!