The Model Context Protocol (MCP) emerged as an open standard for connecting AI assistants to external tools and data sources [1], and adoption followed quickly—an ecosystem of servers now exposes everything from filesystems and databases to ticketing systems and cloud APIs to any compatible agent. That composability solved a real integration problem, and it inherited a set of security problems that the industry has spent the past year mapping in public. The uncomfortable finding is that the properties that make MCP useful—dynamic tool discovery, natural-language tool descriptions, servers written by anyone—are the same properties that create its attack surface. This article reviews what practitioners and security researchers have learned, and which hardening patterns have actually held up.
How MCP Changes the Trust Model
Traditional API integrations have contracts that live entirely in code: a schema, an endpoint, a type system. MCP integrations are different in one crucial way—part of the contract is prose. Servers advertise tools with natural-language names and descriptions, and those descriptions are injected into the model's context so it can decide when and how to call them. That means the model's behavior is shaped by text authored by the server operator, whoever that is. When your agent connects to a first-party server you wrote, this is fine. When it connects to a community server pulled from a public registry, you have effectively granted a third party influence over your agent's reasoning, not just access to its traffic. Security review of an MCP integration therefore has to cover the metadata, not only the code paths—a shift that most existing API security checklists simply do not capture.
Tool Poisoning: Instructions Hiding in Metadata
Security researchers demonstrated early that tool descriptions are an injection channel: a malicious server can embed instructions in a description—visible to the model but easily skimmed past by a human reviewer—that steer the agent to exfiltrate files, invoke other tools, or quietly change its behavior [2]. The technique is commonly called tool poisoning, and it has a nastier sibling sometimes described as a rug pull: a server that behaves impeccably during evaluation and then changes its tool descriptions or behavior after it has been approved and connected. Because clients typically re-fetch tool definitions from the server, an approval granted on Monday says little about what the model reads on Friday. The mitigations that work are unglamorous supply-chain discipline: source servers from trusted publishers, review tool descriptions as untrusted input, pin or hash server versions where your client supports it, and alert on changes to a connected server's advertised tools rather than silently accepting them.
The Confused Deputy Problem, Revisited
The confused deputy is a classic security failure—a privileged program tricked into misusing its authority on behalf of a less-privileged party [3]—and agentic systems reproduce it almost perfectly. An MCP-connected agent typically holds the union of its user's privileges across every connected server: the same session can read internal documents, query a production database, and send email. Nothing in the protocol prevents content that arrived through one low-trust channel from steering the use of a high-trust capability. The canonical worked example is an agent that reads an inbound email or public issue containing hidden instructions and then uses a legitimately connected tool to forward private data outward: every individual tool call is authorized; the composition is the attack. This is why per-integration identity matters. An agent that talks to a low-trust data source should not be the same principal—with the same tokens—as the agent that can act on sensitive systems, and cross-server data flows deserve the same scrutiny as cross-domain flows in a browser.
Prompt Injection Through the OWASP Lens
The OWASP Top 10 for LLM Applications puts prompt injection at the top of the list as LLM01 [4], and MCP deployments demonstrate why: every tool result is a channel through which untrusted text enters the model's context. A web page fetched by a browsing tool, a ticket body returned by an issue tracker, a filename in a directory listing—any of it can contain instructions that the model may treat as authoritative. This is indirect prompt injection, and it composes badly with the confused-deputy dynamics above: injection provides the steering, over-broad tool access provides the blast radius, a pairing OWASP's excessive-agency category describes well [5]. A year of public incident write-ups and red-team exercises supports a blunt conclusion: no reliable, general defense against prompt injection exists at the model layer alone. Filtering and adversarial training raise the bar, but robust deployments are the ones architected so that a successfully injected agent still cannot do much damage—which is an authorization problem, not a prompting problem.
Hardening Patterns That Hold Up
The patterns that have survived production contact are conventional security engineering applied without exception to agent tooling. Least-privilege tool scopes: back each server with credentials scoped to what the agent's task actually requires—read-only tokens where writes are not needed, narrow filesystem roots instead of home directories, per-integration service accounts instead of a user's full OAuth grant. Human-in-the-loop gates: require explicit approval for irreversible or externally visible actions—sending messages, modifying production state, moving money—so injection can propose but not dispose; keep approval prompts specific enough that users are confirming an action, not clicking through a habit. Allowlists over discovery: in enterprise settings, agents should connect only to vetted servers, not whatever a registry offers. Containment and audit: run servers sandboxed with minimal network egress, and log complete tool-call chains—arguments and results included—because reconstructing what an agent actually did is the difference between an incident review and guesswork. None of this is novel; the discipline is applying it before the integration ships rather than after the first incident.
Conclusion
A year of agentic integrations has not produced a silver bullet, and the honest reading of the research is that none is coming: prompt injection remains unsolved at the model layer, and MCP's flexibility will keep attracting supply-chain attacks the way package registries do. What the year did produce is a workable playbook—treat servers and their metadata as supply chain, deny the deputy its excess authority through scoped credentials and per-integration identity, gate the irreversible on a human, and log everything. Teams that apply those patterns get the productivity of agentic integrations at a risk level they can defend to an auditor. Teams that skip them are running someone else's instructions with their own credentials, and the past year suggests they will find out.
References
- [1]Model Context Protocol Specification (2025-06-18) — Model Context Protocol
- [2]MCP Security Notification: Tool Poisoning Attacks — Invariant Labs
- [3]Security Best Practices — Model Context Protocol
- [4]LLM01: Prompt Injection — OWASP Top 10 for LLM Applications — OWASP GenAI Security Project
- [5]LLM06:2025 Excessive Agency — OWASP Top 10 for LLM Applications — OWASP GenAI Security Project