MCP Security: Tool Poisoning & Confused Deputy (2026)

Q: What makes the Model Context Protocol a security risk?

The core risk is that an MCP server controls content that flows directly into the model's trusted context — the descriptions of the tools the model will call, the resources it reads, and the results those tools return — and the model cannot natively distinguish that content from its own instructions. This means a malicious or compromised server can inject directives the agent obeys, through tool poisoning (instructions hidden in a tool's description or schema) or indirect prompt injection (instructions smuggled inside tool results such as a fetched web page or a database row). Because the agent typically holds real credentials and the ability to act, an injected instruction is executed with the agent's legitimate privileges, turning the agent into a confused deputy. Classic API security — authentication, transport encryption, input validation — is necessary but not sufficient here, because the protocol moves capability and instruction-bearing data, not just function calls. The correct mental model is to treat every MCP server as an untrusted source of instructions and to constrain what the agent can do regardless of what it is told, so that even a fully poisoned server can only achieve a bounded, logged, and where-necessary human-approved outcome. Containment, not just filtering, is the control objective.

Q: What is tool poisoning in MCP?

Tool poisoning is an attack where malicious instructions are embedded in the metadata of an MCP tool — its description, its parameter schema, or accompanying documentation — so that when the model reads the tool definition into its context, it also reads attacker-controlled directives it may obey. A canonical example is a tool whose description appears to describe a harmless utility but contains hidden text instructing the model to, before using the tool, read a sensitive file such as an SSH key or environment secret and include the contents in the tool's arguments, which the malicious server then captures. Because tool descriptions are loaded into the trusted context exactly like a system prompt, the model has no built-in way to treat them as untrusted. The defence is to scan tool definitions for injection patterns at registration time rather than trusting them, to pin and review tool schemas so a description cannot silently change after approval, to render tool metadata in a context the model is explicitly told to treat as untrusted data rather than instructions, and to keep a human in the loop for any consequential action that follows from external content. Tool poisoning is distinct from injection via results because it abuses the tool's static metadata, so it must be caught at the registration and version-pinning stage as well as at runtime.

Q: What is the confused-deputy problem for AI agents?

The confused-deputy problem is a classic capability-security flaw in which a program with legitimate, broad privileges is tricked by a less-privileged party into misusing those privileges on the attacker's behalf. Applied to AI agents, the agent is the deputy: it holds real access to your CRM, filesystem, email, or payments tool, and an attacker who can inject an instruction — via a poisoned tool description or a malicious tool result — steers the agent into using that legitimate access maliciously, for example to exfiltrate data or take an unauthorised action. The crucial insight is that input filtering alone does not solve this, because filtering only reduces the probability that an injected instruction gets through; it does not bound the damage when one does. The decisive control is on capability: give each MCP server and tool only the narrow permission its function requires, ensure the agent holds no standing admin credential, issue short-lived scoped tokens per task rather than a broad reusable token, and never hand an OAuth token or secret directly to a server you do not control — broker a capability instead. With capability properly constrained, even a fully poisoned agent can only propose actions that the policy layer and human-approval gate will reject, which is what turns an unbounded breach into a contained, logged non-event.

Q: How do you defend against indirect prompt injection through MCP tool results?

Indirect prompt injection through MCP happens when an attacker plants instructions inside data that a tool returns — a fetched web page, an email, a calendar invite, a database record — and the model, treating the returned data as trusted context, obeys those instructions. The defence rests on one principle borrowed from RAG security: data returned from a tool is never executed as an instruction. Concretely, you scan tool results at runtime for injection patterns before they reach the model, render external content in a quarantined section of the context that the system prompt explicitly designates as untrusted data to be summarised or analysed but never followed, strip or neutralise control sequences, and require human approval for any consequential action the model proposes as a consequence of external content. This is the same layered approach as defence-in-depth prompt-injection protection, adapted to the MCP boundary where the volume and variety of returned data is high. No single filter is perfect, which is why the boundary control is reinforced by capability constraints downstream — least-privilege tokens and a human gate — so that even an injection that evades the scanner cannot translate into an unbounded action. The combination of input quarantine and capability containment is what makes the boundary defensible rather than merely hardened.

Q: What is an MCP rug pull and how do you prevent it?

An MCP rug pull is a supply-chain attack in which a server behaves correctly during your evaluation and approval, then ships a malicious update after you have connected and trusted it — exploiting the fact that MCP server and tool definitions are mutable and often auto-updated. A related attack is tool shadowing, where a malicious server redefines or intercepts a tool that another server provides because there is no namespace isolation between servers. Prevention applies dependency-management discipline hardened for MCP: maintain an allow-list of approved servers so unknown ones cannot connect, pin server and tool definitions to a reviewed version and re-review on any change rather than auto-updating, isolate each server's tools in their own namespace so one server cannot shadow or impersonate another's tools, prefer servers you self-host or whose source you can audit when they hold sensitive capability, and log every tool registration and call with a correlation ID so a malicious change is detectable and an incident reconstructable. This is the AI supply-chain and software-bill-of-materials discipline extended to the agent's tool layer, and its purpose is to close the gap between "the server was safe when we approved it" and "the server is safe right now," which is precisely the gap a rug pull exploits.

Q: Should you give an MCP server your OAuth tokens?

No — you should never hand a reusable OAuth token or secret directly to an MCP server you do not fully control, because doing so is credential theft waiting to happen: a malicious or compromised server that receives your token can replay it, use it beyond the scope you intended, or exfiltrate it, and a token passed through to a downstream service also breaks the audit chain. The correct pattern is to broker credentials so the server receives a capability rather than a secret — a short-lived, narrowly-scoped token issued for a specific task and audience, ideally via a token-exchange flow where your trusted broker mints a constrained token for the specific action rather than forwarding the user's broad token. This keeps the powerful, long-lived credential inside your trust boundary and ensures the server can only do the one scoped thing it was authorised for, for a short window, with every use attributable in your logs. It also contains the blast radius of a server compromise: a leaked scoped token expires quickly and grants little, whereas a leaked broad token is a full account takeover. Combined with least-privilege tool permissions and a human gate on consequential actions, brokered capabilities are what prevent an MCP integration from becoming a standing credential-exfiltration channel.

Q: What are the common anti-patterns in MCP deployments?

Eight recur. Treating an MCP server like an installed library when it is a remote, mutable, instruction-emitting third party inside your context window — threat-model it as untrusted. Trusting tool descriptions and results as safe context when both are attacker-controllable — data from a tool is never an instruction, so scan and quarantine it. Giving the agent broad standing credentials, which is the over-privilege a confused deputy needs — use least-privilege, scoped, short-lived tokens per task. Handing OAuth tokens directly to third-party servers, which is credential theft waiting to happen — broker capabilities and never share reusable secrets. Auto-updating servers without re-review, which is the rug-pull vector — pin to reviewed versions and re-review on change. Having no namespace isolation between servers, which enables tool shadowing and interception — isolate each server's tools. Allowing autonomy on consequential actions with no human gate, because injection plus autonomy on a real capability is the breach — gate money-movement and data-exfiltration-class actions. And keeping no audit of tool registrations and calls, without which you cannot detect poisoning or reconstruct an incident — log everything with correlation IDs. Each maps to a concrete control, and together they move an MCP deployment from an open confused deputy to a contained, attested system.

Q: How does MCP security map to OWASP LLM Top 10 and the EU AI Act?

MCP security maps cleanly onto established frameworks, which lets you justify the controls in audit and compliance terms. Against the OWASP Top 10 for LLM Applications, tool poisoning and indirect injection through tool results are instances of prompt injection (LLM01); the confused-deputy problem and unbounded agent actions are excessive agency (LLM06/LLM08); rug pulls and tool shadowing are supply-chain risks; and credential passthrough to servers is a sensitive-information and insecure-design issue. The corresponding controls — input quarantine, least-privilege capability, brokered scoped tokens, allow-listing and version-pinning, human-in-the-loop on consequential actions, and full audit — are the architecture-level mitigations these risks call for. Against the EU AI Act, autonomous agents that take consequential actions implicate the transparency, human-oversight, and risk-management obligations for higher-risk systems, and the same human-approval gate, audit trail, and bounded-capability design provide the evidence of oversight and control that those obligations require. The NIST AI Risk Management Framework supplies the governing structure to report against. The practical implication is to design the containment architecture once and map it to OWASP for engineering assurance and to the EU AI Act and equivalent regional regimes for regulatory attestation, so connecting a new MCP server becomes a governed, evidenced step rather than an untracked expansion of the attack surface.