MCP Tool Poisoning: How Trusted AI Integrations Can Become an Attack Path

Executive Summary

MCP allows AI applications to discover and invoke tools exposed by external servers. Depending on the connected system and its permissions, those tools may read files, query repositories, retrieve messages, modify records, send communications, or initiate other consequential operations. The protocol does not make every tool malicious. The risk emerges from how individual clients and agent frameworks interpret tool metadata, combine it with other context, request permissions, and execute resulting actions.

A representative attack chain has five stages:

1. Establish trust. A user or administrator connects an MCP server because it offers useful functionality.
2. Introduce malicious instructions. A tool description or external content contains instructions that attempt to redirect the agent's behavior.
3. Exploit inherited capabilities. The agent has access to other tools, private data, or credentials through its normal operating environment.
4. Trigger an unauthorized sequence. The agent retrieves information or invokes tools beyond the user's intended task.
5. Move or expose data. Sensitive information is included in an external request, message, repository change, or other permitted-looking operation.

The individual calls may appear legitimate when examined in isolation. A repository read, a file access, or an API request might normally be allowed. The security failure lies in the relationship between the original task, the instruction that influenced the agent, the data accessed, and the final destination. This is why ordinary authentication and tool approval are insufficient as the sole security controls.

The defensive objective is not simply to identify malicious MCP servers. It is to ensure that an agent cannot convert an untrusted instruction into an unauthorized action merely because the relevant tools are available.

Incident and Research Timeline

April 1, 2025 — Tool Poisoning Disclosed

Invariant Labs published its research on tool-poisoning attacks. The researchers demonstrated that instructions embedded within MCP tool descriptions could induce an agent to read sensitive local files and pass their contents through tool parameters. A tool presented as a simple calculator, for example, could carry additional instructions directing the agent to inspect configuration files or private keys. The user-facing tool summary did not necessarily reveal the full instruction set available to the model.

The research also described tool shadowing: a malicious server could attempt to influence the agent's behavior when interacting with another, trusted server. Connecting multiple individually useful tools can create a combined attack surface that is not obvious from reviewing each tool separately.

April 7, 2025 — WhatsApp Data-Exfiltration Demonstration

Invariant Labs published a follow-up demonstration involving WhatsApp-connected MCP tooling. The research showed how a malicious MCP server could attempt to influence an agent to expose WhatsApp message history through a connected workflow — exploiting the agent's access to another service, even when that service was not the source of the malicious instructions.

The research also highlighted the risk of a rug pull: a server initially presents benign behavior, then changes its tool descriptions after the user has already approved the integration. One-time approval is therefore an incomplete security measure.

May 26, 2025 — GitHub MCP Vulnerability Disclosed

Invariant Labs disclosed research involving the official GitHub MCP integration. In the demonstration, a malicious GitHub issue contained instructions that manipulated a connected coding agent. The agent was induced to retrieve private repository information and expose it through a pull request in a public repository.

The important distinction: the attack did not require the MCP server itself to be compromised. The agent's access to GitHub, combined with untrusted issue content and the model's tool-use behavior, created the path to disclosure. Trusted tools can be used unsafely when untrusted content influences the sequence of actions performed through them.

June 30, 2026 — Enterprise Finance-Workflow Attack Pattern

Microsoft published an analysis of MCP tool poisoning in a finance workflow. The scenario involved an AI agent connected to a vendor master system, email, and a third-party invoice-enrichment MCP server. A modification to the enrichment server's tool description introduced instructions to retrieve unpaid invoices and attach their contents to an otherwise routine enrichment request.

Microsoft emphasized that the pattern did not require a vulnerability in Copilot itself. The risk arose from the trust boundary between the agent and its external tool integrations. Microsoft did not disclose a specific affected organization.

October 2026 — Security Implications

The available research and vendor guidance point to a consistent conclusion: MCP integrations must be managed as production dependencies, and sensitive agent actions require independent authorization. Security teams should review tool metadata, monitor changes, limit permissions, validate data flows, and enforce policies on actual execution paths.

Attack Chain and Technical Root Causes

The attack class is best understood as a sequence of trust failures rather than a single protocol exploit.

Stage 1 — A Trusted Integration Enters the Environment

An organization connects an MCP server to provide a useful capability: repository access, messaging, document retrieval, financial analysis, or database queries. The server may be legitimate and may initially behave as expected. The organization may review its publisher, approve its installation, and authorize it to use a particular set of tools.

However, approval often focuses on the server's stated purpose rather than every action the agent might perform through it. Security failure: The organization treats integration approval as a durable authorization decision for future behavior. Defensive requirement: Maintain an inventory of approved MCP servers, their owners, their available tools, their permissions, and the resources those tools can access.

Stage 2 — Tool Metadata Becomes an Instruction Channel

MCP tool descriptions tell the agent what a tool does and how it should be used. In agentic systems, that text can influence model behavior. A malicious description may contain instructions unrelated to the tool's legitimate purpose. It may direct the agent to read sensitive files, include private information in arguments, or alter the way it uses another connected tool.

Security failure: Natural-language metadata is allowed to influence behavior without being treated as a potentially security-sensitive input. Defensive requirement: Review complete tool descriptions and schemas, detect changes, pin approved versions where feasible, and require renewed review when security-relevant metadata changes.

Stage 3 — The Agent Uses Legitimate Permissions for an Unintended Purpose

The agent may have legitimate access to private repositories, email, local files, or financial records. The malicious instruction attempts to redirect those capabilities toward a purpose the user did not authorize. This is a confused-deputy problem: the agent can use privileges available to it to carry out a sequence that benefits an attacker or violates the original task's scope.

Security failure: The system assumes that an authenticated agent making a permitted API call is performing an approved task. Defensive requirement: Evaluate the requested action, target, identity, and applicable policy independently of the model's explanation for why the action is necessary.

Stage 4 — Cross-Tool Influence Creates a Larger Attack Surface

Agents often connect several tools in the same session. A malicious tool may attempt to influence calls to a different tool, or untrusted content returned by one tool may redirect the agent toward another. For example, content retrieved from a repository might instruct an agent to search local files and publish the results elsewhere.

Security failure: Individual integrations are assessed separately, while the agent can combine their capabilities into a single workflow. Defensive requirement: Evaluate the complete chain of actions and data movement, not only each tool's isolated function.

Stage 5 — Sensitive Information Leaves Its Intended Boundary

The final step may look like an ordinary operation: sending a message, creating a pull request, submitting an API request, or uploading a document. If sensitive information is embedded in the operation, a destination that appears legitimate may still receive data it should never have received.

Security failure: The organization validates the connection and identity but does not sufficiently constrain the action's data, target, and purpose. Defensive requirement: Enforce destination restrictions, inspect sensitive payloads where appropriate, limit data access, and record the chain from request through execution.

What Failed Conceptually?

The following are defensive conclusions drawn from the public research—not claims that every listed weakness existed in every affected system.

1. Integration Trust Was Mistaken for Action Trust

An organization may reasonably trust a publisher without trusting every future instruction that its software supplies. A server's initial approval does not establish that subsequent metadata changes are safe. Nor does it establish that every action performed through the server is appropriate for every task.

The relevant question is not only, "Do we trust this MCP server?" It is, "Is this action authorized for this agent, against this target, right now?"

2. Tool Descriptions Were Treated as Documentation Rather Than Security-Sensitive Inputs

Descriptions can influence how an agent selects and uses tools. If a description changes, the agent's behavior may change even when the visible tool name remains the same. This creates a supply-chain problem that traditional software dependency scanning may not fully address.

3. Authentication Did Not Establish Intent

A valid token can prove that an operation is associated with a particular identity. It does not prove that the operation serves the user's intended purpose. If an agent is authorized to read a repository and create a pull request, those permissions may still enable an unsafe sequence: retrieve confidential information from one location, then publish it to another.

4. Human Approval Was Not Necessarily Informed Approval

A confirmation dialog is useful only if the person can understand what they are approving. If the interface displays a generic tool name but hides sensitive arguments, destinations, or side effects, a user may approve an action without understanding its actual impact.

5. The Security Boundary Ended Too Early

Securing the model's prompt does not secure every action the model can trigger. A prompt-injection defense may identify suspicious instructions, but an agent may still receive malicious content that changes its behavior. Security must therefore extend to the execution path, where the system can determine whether the requested operation is permitted.

Defensive Controls and Runtime Enforcement

The following framework is intended for CISOs, platform engineering teams, AI infrastructure owners, and security architects deploying MCP-enabled systems.

Control 1 — Govern the MCP Supply Chain

Treat each MCP server as a production dependency. Maintain a registry of approved servers, publishers, owners, and environments. Disable unrestricted tool access when explicit tool selection is possible. Review complete descriptions and schemas before production deployment. Track changes to metadata and require re-approval for sensitive changes.

Control 2 — Enforce Authorization at the Action Boundary

Evaluate consequential actions before they execute. A policy decision should consider, where available: agent identity and role; requested tool and operation; target resource or destination; read, write, execute, delete, or administrative privileges; relevant data sensitivity and organizational restrictions; approval requirements for high-impact actions.

Control 3 — Restrict Data Movement

Prevent the agent from treating access to information as permission to disclose it. Apply least-privilege access to repositories, files, databases, and messaging systems. Restrict outbound destinations to approved services where practical. Inspect sensitive outbound payloads using appropriate data-loss-prevention controls.

Control 4 — Treat Tool Outputs as Untrusted

An MCP response may contain useful information, malicious instructions, or content that attempts to influence later steps. Agents should not automatically treat tool output as authority to perform additional actions. Use input validation, structured data contracts, contextual prompt-injection defenses, and explicit authorization for subsequent tool calls.

Control 5 — Control Identity and Credentials

Use distinct identities for agents and workloads wherever practical. Scope credentials to the resources and actions required. Prefer short-lived credentials and rotate exposed secrets. Avoid broad administrative credentials in agent environments.

Control 6 — Monitor Behavior Across Tool Chains

Logging individual MCP calls is not enough if the attack depends on a sequence of otherwise normal actions. Monitor for patterns such as: new or unexpected tool descriptions; sudden changes in tool arguments; access to files or repositories unrelated to the task; large or unusual data retrievals; unexpected external destinations.

Control 7 — Prepare for Containment

Organizations should be able to disable a compromised integration, revoke its credentials, isolate an agent, and halt sensitive operations. Incident-response procedures should identify who can take these actions and how quickly they can be performed.

Where AI Runtime Security Fits

MCP security is not solved by one product category. Model-level safeguards can reduce the likelihood that an agent follows malicious instructions. Tool reviews and supply-chain controls reduce exposure to compromised integrations. Identity controls limit permissions. Network restrictions constrain destinations. Data-loss prevention can block sensitive transfers. Monitoring supports investigation and response.

Runtime enforcement addresses a distinct question: Should this particular action be allowed to execute under the applicable policy?

That question remains important even when the model is behaving as designed from its own perspective. A model can interpret a malicious tool description as a legitimate instruction. An agent can construct a valid API request that violates the user's intent. A tool can be authenticated and authorized for one purpose while being used as part of an unsafe sequence. An independent enforcement layer can evaluate covered actions against explicit rules rather than relying solely on the agent to judge its own behavior.

Runtime enforcement has important limits. It cannot guarantee protection for actions that bypass it, repair vulnerable MCP servers automatically, or replace secure credential management and network isolation. Its effectiveness depends on accurate policies and comprehensive coverage of the execution paths that matter.

The Role of SAILLENT

SAILLENT focuses on runtime enforcement at the action boundary for autonomous AI systems. The central principle is straightforward: a model can propose an action, but that proposal should not itself grant permission to execute it.

Where deployed and configured on the relevant execution path, SAILLENT can evaluate covered tool actions against explicit policy and deny operations that are not permitted. This is relevant to AI agents connected to MCP servers, APIs, developer infrastructure, and other systems capable of accessing sensitive data or changing state.

For MCP-enabled environments, SAILLENT's relevant controls include: the provenance invariant (which resolves tool names against a trusted registry rather than trusting agent-supplied identifiers), the ToolRegistry relationship verification (which independently validates that an agent is authorized to use a specific tool), and the Floor-RAISER impact model (which prevents policies from downgrading the security posture of tool operations). These are implemented in saillent-boundary/src/boundary.rs and saillent-core/src/policy.rs.

The model decides what to propose. Policy determines what is authorized. Enforcement determines whether the covered action proceeds.

A checklist is only a starting point. High-risk deployments should validate these controls with repeatable adversarial tests and documented evidence.

FAQs and Primary Sources

Is MCP itself inherently insecure?

No. MCP is a protocol for connecting AI applications with tools and data sources. The risk depends on the implementation, the trust placed in tool metadata and outputs, the permissions granted to agents, and the controls applied to consequential actions.

Was there one confirmed MCP breach behind all these reports?

No. The research and scenarios covered here are distinct. Invariant Labs published attack demonstrations involving tool poisoning, WhatsApp-connected tooling, and GitHub MCP behavior. Microsoft published an enterprise finance-workflow attack pattern but did not identify a specific affected organization.

What is a tool-poisoning attack?

It is an attack in which malicious instructions are embedded in a tool description or related metadata to influence an agent's behavior. Depending on the client's behavior and available permissions, the agent may attempt unintended actions or disclose information.

What is an MCP rug pull?

A rug pull occurs when a previously approved server changes its behavior or tool metadata after the initial trust decision. If changes take effect without meaningful review, the agent may be exposed to new instructions that were not part of the original approval.

Can tool poisoning work when the MCP server is legitimate?

Yes. A malicious instruction may arrive through untrusted content returned by a legitimate service. The GitHub MCP research demonstrated a path in which malicious issue content influenced an agent using a trusted integration.

Can runtime enforcement stop MCP tool poisoning?

It can reject unauthorized actions that traverse its configured enforcement points and are correctly represented by the applicable policy. It cannot guarantee that every malicious instruction is detected, prevent actions outside its coverage, or replace permissions management, secure integrations, and data-protection controls.

What should enterprises do first?

Inventory connected tools, review metadata and changes, reduce permissions, constrain data movement, test cross-tool attack paths, and ensure sensitive actions are independently authorized before execution.

Conclusion: Tool Trust Is Not Action Authorization

MCP is becoming an important part of the infrastructure that connects AI agents to enterprise systems. That connectivity creates value, but it also allows instructions from one source to influence actions performed through another.

The central risk is not simply that an MCP server might be malicious. It is that an agent can combine untrusted instructions, legitimate permissions, and multiple tools into a sequence that violates the user's intent.

The response must therefore extend beyond model alignment and initial integration approval. Organizations need controlled tool supply chains, least-privilege identities, constrained data flows, meaningful approval for high-impact operations, and reliable enforcement on the actual execution path.

Trust the integration only as far as it has been verified. Authorize each consequential action independently. Enforce the boundary before execution.

That is the foundation of runtime security for connected AI agents.