Prompt Injection via Third-Party MCP Servers

In the Model Context Protocol, every tool-call response gets appended straight into an agent's active context, and the model reads that text as instruction, not as quarantined data. Because of that design, third-party MCP servers can structurally deliver prompt injection on every call, not just occasionally.

Why MCP's architecture makes every tool-call response an injection opportunity

MCP flips a pattern that's been stable in software for decades. Instead of a client asking a server for data and keeping the response at arm's length, MCP often has servers querying and executing actions on behalf of connected clients. The NSA's Cybersecurity Information Sheet from May 2026 calls this an inversion, and it's the right word for it: the attack paths it opens are new, and most organizations haven't mapped them yet.

The protocol makes no distinction between a trusted prompt and untrusted tool output. Whatever text a tool call returns becomes part of the reasoning context, and the model uses it to decide what to do next. A Jira ticket, a Slack message, a database row, a scraped webpage: if an attacker controls the contents of any of these, the attacker controls what the model reads, and by extension what the model does next.

This isn't a bug Anthropic missed when it designed the spec. MCP standardizes how models discover and call tools, but it deliberately leaves authorization and input validation to each implementer. The cost of that flexibility is that every implementer now has to build the security the protocol declined to mandate.

Tool response goes into context, context becomes instruction, instruction becomes action. Every section after this one is a variation on that chain.

How indirect prompt injection travels through a third-party server

Indirect prompt injection is the dominant form this threat takes. Practical DevSecOps's 2026 analysis logged a 540% surge in HackerOne prompt-injection reports, and the mechanism behind that surge is consistent: the attacker never touches the user's prompt. Instead, the attacker poisons the data a tool will fetch and hand back to the model.

The path runs the same way across cases. An attacker plants malicious instructions inside a resource the MCP server is likely to retrieve, a support ticket, a git commit message, a webpage, a database row, a Slack message. The agent calls the relevant tool legitimately, on the user's behalf, with no malicious intent anywhere in the chain so far. The server fetches the poisoned resource and returns it as ordinary tool output. That output gets appended to the model's context, and the model reads the embedded instructions as directives to act on. The user sees none of this. From where they sit, the agent is simply doing its job.

The GitHub MCP exploit that Invariant Labs documented in May 2025 shows the pattern cleanly. An attacker created a GitHub Issue containing a prompt injection. The agent, checking open issues through the GitHub MCP server as part of routine work, read the injection, followed the embedded instructions, and exfiltrated contents from private repositories the user had authorized it to access. The agent's authorization was entirely legitimate. The injection simply redirected that authorization against the person who granted it.

The Supabase case from July 2025 adds a second dimension: how much the blast radius depends on what the agent is allowed to touch. A Cursor agent, running with privileged service-role access, processed support tickets that carried user-supplied input. Attackers hid SQL instructions inside those tickets, and when the agent read them, it exfiltrated sensitive integration tokens into a public support thread. Three factors stacked here: privileged access, untrusted input, and an external communication channel the data could leave through. Each factor alone is manageable with ordinary care. Combined, they produced an outcome categorically worse than any one of them would have caused on its own. That combination, and how much it amplifies damage, is the thread the next two sections pull on.

Three attack variants that exploit the same structural opening in different ways

Indirect prompt injection is the root mechanism, but it isn't the only way attackers exploit the same structural opening. Tool poisoning, rug pull attacks, and cross-server shadowing each weaponize the same untrusted-text-into-context problem, but with different timing and different targets.

An attacker manipulates a tool's name, description, or parameter hints, which causes the agent to invoke the wrong tool, escalate privileges, or take unauthorized actions. The exploit chain researcher Yarden Porat documented against Anthropic's official Git MCP Server in January 2026 shows how far this can go: three separate CVEs, an unrestricted git_init (CVE-2025-68143), an argument injection flaw (CVE-2025-68144), and a path validation bypass that defeated repository scoping (CVE-2025-68145), chained together into remote code execution achieved through prompt injection alone. This happened against an official server built by the company that created the protocol. A separate case in April 2026, an authentication bypass in Microsoft's @azure-devops/mcp tracked as CVE-2026-32211 with a CVSS score of 9.1, let attackers pull API keys and tokens without presenting any credentials at all.

Rug pull attacks exploit a different gap: MCP has no built-in mechanism for tracking changes to a tool's definition or requiring a user to re-approve it after a change. A server first earns a user's trust by presenting benign, genuinely useful tools during initial setup. Later, in a subsequent session, the server quietly modifies what those tools actually do. The agent keeps transacting with the server, session after session, with nothing in the protocol flagging that anything changed. The attack surface grows every time the agent runs, because once you grant trust, nothing makes you look at it again.

Cross-server shadowing targets the multi-server deployments common in enterprise settings. A malicious MCP server can use its own tool descriptions to interfere with how legitimate servers behave inside the same agent session. A plausible pattern: instructions buried in one server's tool description tell the agent to send a copy of any outgoing email to an attacker-controlled address, triggered whenever any send_email tool, from any connected server, gets invoked. This matters because enterprise deployments routinely connect agents to many MCP servers at once, so a single compromised server can reach across the whole session.

A fourth pattern, really a variation on supply chain compromise, appeared in the ClawHub marketplace case in February 2026. Koi Security first disclosed a large number of malicious skills distributed across ClawHub, the marketplace serving the OpenClaw AI agent framework, with Antiy CERT later confirming the total. Here the poisoned artifact was the server itself, and it reached the marketplace before it ever fetched a single resource. That distinction matters for the defense section later on.

Why agent permissions determine how bad an injection gets

Prompt injection and tool poisoning stay bounded if the agent carrying them has limited reach. They stop being bounded the moment the agent has write access to production systems, can send email on a user's behalf, or can modify code in active repositories. What the agent is authorized to do determines the severity of an incident, beyond what the attacker manages to inject. A 2026 industry analysis found that 47 to 53% of organizations have had AI agents exceed their permissions or suffer an incident tied to this exact gap.

The Agentjacking case tied to Sentry's MCP server, documented by Tenet Security in June 2026, shows what happens when the response to a structural problem is a surface-level patch. Injectable DSNs affected a large number of organizations, and when tested, agents executed against them at a high rate. Sentry declined to remediate the underlying issue and instead deployed a filter matching known payload strings. A string filter catches the exact payloads it was built to catch. It does nothing against a new payload string, because the filter was built to match known payloads rather than to close the structural opening that lets injected text act as instructions.

The clearest illustration of blast radius at scale is the Mexico government breach that unfolded between December 2025 and February 2026. An attacker used an AI assistant to breach multiple government bodies at once: the federal tax authority, the electoral institute, four state governments, and a water utility. The breach exfiltrated taxpayer records, voter files, civil registry documents, and government employee credentials, and the attacker's own conversation logs were later found sitting publicly accessible online. The breach reached as far as it did because the agent involved had broad access across these systems, and nothing in the chain was positioned to detect or interrupt instruction-following that served the attacker instead of the legitimate user.

What the compliance frameworks say about agentic injection

The frameworks most enterprises lean on for security assurance were built before autonomous agents existed in their current form, and they don't cover the agentic attack surface described in the previous sections. That gap holds regardless of how rigorously an organization pursues SOC 2 or ISO 27001 compliance, because those frameworks were never built to see this risk in the first place.

The OWASP Top 10 for Agentic Applications 2026 identifies the ten highest-impact threats facing agents that plan, act, and make decisions across complex workflows. Measured against that list, SOC 2 fully covers none of the ten risks, and neither does ISO 27001. This is a gap in the frameworks themselves, independent of how well any given organization implements them.

The exposure that follows isn't abstract. If an agent covered by SOX, GDPR Article 32, or the EU AI Act's obligations for high-risk systems gets compromised, compliance violations become possible. An organization can pass every audit on its books and still carry this exposure, because the audits weren't built to look for it.

The NSA's Cybersecurity Information Sheet recommends that organizations operating in high-stakes environments scan networks regularly to find insecure or unauthorized MCP servers before an attacker finds them first. Most organizations haven't built that scanning into their operations yet, which leaves the recommendation sitting ahead of practice rather than describing it.

The authentication and authorization response and its current limits

The protocol and the ecosystem around it haven't stood still. Real governance work has shipped over the past year, even as the dominant enterprise defense pattern, OAuth 2.1 paired with allowlists and logging, runs into a structural limit that none of this work has closed yet.

The MCP specification's July 2026 revision, dated 2026-07-28, brought a stateless protocol core, Multi Round-Trip Requests, header-based routing, cacheable list results, hardened authorization, a formal extensions framework, and updated Tier 1 SDKs. The most consequential piece of that update is the Enterprise-Managed Authorization extension, now stable, and with it organizations can centrally provision MCP server access through their identity provider. Users get connected servers the moment they first log in, with no per-app OAuth flow required. Anthropic, Microsoft, and Okta have adopted it, and early server-side adopters include Asana, Atlassian, Canva, Figma, Granola, Linear, and Supabase.

Alongside that, the community has converged on a set of credential patterns treated as baseline practice: OAuth 2.1 with PKCE for anything user-facing; token exchange under RFC 8693 instead of forwarding a single upstream token downstream, since token exchange issues a fresh credential scoped to the specific target rather than letting one token work against multiple servers; and the guidance in the OWASP MCP Cheat Sheet against sharing OAuth tokens across servers or running any MCP server with full host access or wildcard permissions.

None of this closes the registry gap. The official MCP registry launched in preview on September 8, 2025, with namespace and vendor verification built in. But community registries, Smithery, mirrors of mcpservers.org, arbitrary GitHub URLs, remain the dominant way people actually install servers, and none of them carry consistent verification. Gateway and identity controls only work as well as an organization's ability to prevent shadow MCP in the first place, and developers and business units routinely connect agents to internal APIs without central IT ever finding out.

The deployment numbers make the gap between specification and practice hard to miss. Practical DevSecOps's 2026 analysis found that only 8.5% of public MCP servers use OAuth, and a large share of internet-exposed servers hand their full tool catalog to anonymous callers with no authentication at all. The ClawHub case is the clearest illustration of where this leaves a defender. The malicious artifact there was the server itself, distributed through a marketplace before a single tool call ever ran. Runtime authorization on a verified server does nothing against a server that was never verified to begin with.