What are the security risks of MCP (Model Context Protocol)?

What is MCP?

The Model Context Protocol (MCP) is an open standard, introduced by Anthropic in late 2024, that gives AI models a uniform way to call external tools and data. An MCP client, typically an AI assistant or agent, connects to MCP servers, and each server exposes tools such as database queries, file access, code execution, or actions in SaaS applications.

Adoption spread fast across major AI vendors and thousands of community-built servers. That growth is why the security question matters: every MCP server is a bridge between a probabilistic model and real systems of record. The protocol itself is not the weak point. The weak points appear where the protocol meets credentials, networks, and untrusted content.

Why are MCP servers high-value targets?

An MCP server is an authorization intermediary. To do useful work it holds standing credentials for the systems behind it: API keys, OAuth tokens, database connection strings, cloud roles. Authority that was once spread across many individual integrations gets concentrated into one process that any connected model can drive.

That concentration changes the blast radius. Compromising one MCP server can yield access to every downstream system it fronts, which makes these servers a new and dense form of secret sprawl. Exposure is not hypothetical: Knostic researchers mapped 1,862 MCP servers reachable on the public internet in 2025, and every one of the 119 servers they manually sampled disclosed its tool listings without any authentication.

What is the confused deputy problem in MCP?

A confused deputy is a program with legitimate authority that is tricked into using it on behalf of a less privileged party. MCP servers fit the pattern exactly: the server acts with its own broad credentials for many callers, and if it cannot tell who originated a request, or why, a low-privilege caller can drive high-privilege actions.

A related failure is token audience and context loss. A token minted for one hop gets redeemed at another, and each hop strips information about the original requester and their intent. The June 2025 MCP specification addressed part of this by requiring clients to implement RFC 8707 resource indicators, so each access token is bound to the specific server it was issued for.

Audience binding stops token replay between servers. It does not restore purpose or provenance. A correctly audience-bound token still says nothing about which human or agent started the chain, or whether the requested action matches what was originally approved.

What risks come from unvetted community servers?

Anyone can publish an MCP server, and installing one grants it standing access to whatever credentials it is configured with. The ecosystem inherited every classic software supply chain risk, plus new ones specific to how models read tool metadata.

Implementation quality is also uneven. In 2025, Equixly tested popular MCP server implementations and found command injection flaws in 43%, server-side request forgery paths in 30%, and path traversal or arbitrary file read in 22%.

• Tool poisoning: malicious instructions hidden in tool descriptions that the model reads and follows, invisible in normal UI review
• Rug pulls: a server that behaves correctly at approval time, then changes its tool definitions or behavior in a later update
• Typosquatting and lookalike servers that impersonate popular integrations to harvest tokens
• Overbroad defaults: servers that request wide scopes or run with credentials far exceeding what their tools need

How does prompt injection reach MCP tools?

Indirect prompt injection turns MCP's strength into an attack path. When a model reads untrusted content, such as a webpage, email, or support ticket, instructions embedded in that content can steer it. Without tools, the damage is a bad answer. With MCP tools attached, the injected instructions become actions: queries run, files read, messages sent.

Researcher Simon Willison calls the dangerous combination the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. Many MCP deployments assemble all three by default. The attack surface also includes the server side itself, since tool descriptions and tool results are model-readable channels that an attacker-controlled server can use to inject instructions.

How do you reduce MCP security risk?

The controls are familiar identity and least-privilege practices applied to a new intermediary. The unifying principle: never let authority cross a trust boundary without carrying who asked, what they were allowed to do, and where the request came from.

Walk through a toxic agent flow

The abstract risks become concrete in a single chain of ordinary steps. A hypothetical: picture a developer who connects their AI assistant to a widely used MCP server that fronts their source control. The server holds one credential with read and write access across the developer's public and private repositories. Nothing about this setup is unusual, and nothing in it is misconfigured. It is the default a busy engineer would choose.

An attacker files an issue in one of the developer's public repositories. The issue text is normal on the surface, but it carries hidden instructions written for a model rather than a person. Later the developer asks the assistant to triage open issues. The agent fetches the poisoned issue, and because the model treats retrieved content as context worth acting on, it follows the buried instructions. This is indirect prompt injection meeting live tool authority: the same reach that makes the agent useful is the reach the attacker now borrows.

Obeying the hidden text, the agent reads private repository contents it already had credentials for and writes them into a public pull request the attacker can watch. In 2025 the security firm Invariant Labs disclosed exactly this pattern, which they named a toxic agent flow, against the official GitHub MCP server. Their key observation was that the server code was not flawed. The failure lived in the agent system that fused private authority with untrusted input, which is why the vendor could not close it with a server-side patch alone. It is a textbook case of excessive agency turning a bad answer into data exfiltration.

Every action in that chain used sanctioned permissions. No credential was stolen, no CVE was exploited, and no alert fired on a failed login. The attack maps directly to OWASP's MCP06:2025 Intent Flow Subversion entry and to the lethal trifecta described earlier, and it is the reason MCP risk cannot be reasoned about at the level of a single server in isolation. The unit of failure is the request, not the process.

How do you deploy an MCP server safely?

Safe deployment treats the server as identity infrastructure with a lifecycle, not as a script you install and forget. The controls below map static and runtime discipline onto the sequence a team actually follows, from picking a source to shutting a compromised server down. None of them are novel. They are ordinary identity hygiene applied to a new and unusually powerful intermediary.

• Vet and pin the source: install only from an allowlist of reviewed servers, pin exact versions so a later update cannot silently rewrite tool definitions, and verify provenance and integrity before the server ever holds a credential
• Scope credentials down: replace the single broad secret with per-tool grants that follow least privilege, so compromising one tool does not hand over everything the server can reach
• Prefer short-lived over standing: issue ephemeral credentials per session or task and grant reach through just-in-time access, so no idle authority sits waiting to be abused, a direct answer to the credentials that never expire problem
• Authenticate every caller: implement MCP authentication and RFC 8707 resource indicators so each token binds to this server and cannot be replayed against another
• Separate untrusted input from tool authority: require explicit human approval before state-changing actions such as writes, payments, or production changes, and keep a clear boundary between content the model reads and the tools it can invoke
• Log, baseline, and revoke: record every tool call with the identity and scopes behind it, compare against a per-server baseline, and keep a tested path to revoke a server's credentials immediately when its behavior drifts

Why doesn't audience binding close the loop?

It is tempting to read the June 2025 specification change as a fix. RFC 8707 resource indicators solve one precise problem: a client now requests a token naming the resource it intends to call, and the authorization server mints a token whose audience is that single server. Steal the token and redeem it elsewhere, and it is rejected. Replay between servers, the classic way authority leaks sideways, is closed.

What audience binding does not carry is purpose or origin. Within its valid audience, a correctly bound token still says nothing about which human or agent started the chain, or whether the action about to run matches what that principal approved. In a multi-hop chain, where an agent calls one server that calls a second, each boundary should perform a fresh token exchange and mint a new narrowly scoped token. In practice many deployments reuse one broad token across every hop, which collapses the benefit the specification was meant to provide. Even done perfectly, an on-behalf-of flow propagates the user's identity but not their reason for acting.

That gap is why static token hygiene alone cannot answer the question the toxic agent flow raises. The token was valid, the audience was correct, and the action was still wrong. Provenance and intent are properties of a request, and they can only be checked where the request executes. Keeping delegation chains attributable, so every downstream call traces back to an originating human and an approved purpose, is the part of the problem the wire format was never designed to solve.

Common mistakes when securing MCP

Most MCP incidents trace back to a small set of recurring assumptions, each reasonable in isolation and dangerous once an autonomous caller is attached. Naming them makes them easier to catch in review.

• Trusting install-time review as if it were permanent: a server that behaves correctly at approval time can change its tool definitions in a later update, so a one-time check does not cover a rug pull
• Running the server under a human's OAuth grant or a shared account, which gives the agent no identity of its own and points every audit trail at a person who never took the action
• Treating tool descriptions and tool results as inert data, when both are model-readable channels an attacker-controlled server can use to inject instructions
• Sharing one broad credential across every tool the server exposes, so a single compromise inherits the full blast radius instead of one tool's narrow scope
• Assuming an internal network makes a server safe, when injection travels in through content and concentrated secrets travel out regardless of where the process runs
• Shipping without a revocation plan, so a server behaving badly at 2 a.m. has no tested off switch and the incident runs until someone rotates credentials by hand

Frequently asked questions

Related terms