AI Red Teaming for MCP Tool-Calling Surfaces

Red teaming MCP tool-calling surfaces is not a variation on traditional application security testing. It is a categorically different discipline, and treating it otherwise produces a false sense of coverage. The threat model has to be rebuilt from the ground up, organized around the specific ways agents consume tool context: tool poisoning, prompt injection via tool outputs, intent drift across multi-turn sequences, and unauthenticated tool exposure at deployment scale. The public MCP server registry grew from roughly 1,200 entries in Q1 2025 to over 9,400 by mid-April 2026, more than seven times in fourteen months. The attack surface is expanding faster than security practice can track it. This piece is a working methodology, not a survey of the landscape.

The confirmed vulnerability landscape red teamers are actually working against

Ninety-nine CVEs were published for MCP-related software in 2025 alone. Tool poisoning moved from theoretical risk to live, exploited attack within that same window. The incident record is specific enough to anchor a threat model.

Three incidents illustrate three distinct attack classes.

In September 2025, a fake npm package impersonating a legitimate MCP integration built trust across fifteen published versions before silently BCC'ing all outbound email to an attacker. The operative tactic was patience: establish legitimacy, then weaponize. This is a supply chain attack, and its multi-version patience is what makes it distinctive. It does not look like an intrusion; it looks like a dependency.

In January 2026, over 2,000 MCP instances leaked credentials and full conversation histories through unauthenticated deployment gateways. This was not a protocol vulnerability. It was misconfiguration at scale, the predictable outcome of developer-spun infrastructure operating outside organizational security governance.

The GitHub MCP prompt injection is the cleanest illustration of indirect injection. Malicious content embedded in GitHub issues, standard user-generated data, hijacked agents into exfiltrating private repository contents through a fully legitimate, unmodified tool. The tool itself was clean. The data it retrieved was the weapon.

Then there is the OX Security disclosure from April 2026, which documented a systemic design flaw in Anthropic's core MCP STDIO transport: direct configuration-to-command execution without input sanitization. Cursor, VS Code, Windsurf, Claude Code, and Gemini-CLI were all affected, representing over 150 million downloads and producing more than ten Critical or High CVEs from a single root cause. Anthropic confirmed the behavior is intentional. Sanitization is the developer's responsibility. That is a signal to red teams, not a criticism of Anthropic. The protocol does not assume a sanitized environment, and your methodology cannot either.

These incidents map almost exactly onto four discrete threat classes. A rigorous methodology addresses each one deliberately, not as variations on a general prompt injection theme.

The four threat classes that define the MCP red team scope

Tool poisoning and rug-pull attacks

Tool poisoning is the embedding of adversarial instructions inside tool descriptions, parameter schemas, or server response content, in fields the agent treats as trusted operational context rather than as inert data. There is no native MCP mechanism that detects or prevents these injections. Trust inheritance from server to client is unconditional by default.

The rug-pull variant is more insidious. A server publishes a legitimate tool and waits for adoption. Once adoption is established, the server operator modifies the tool description to carry malicious instructions. Unlike a code change in a package manager, a natural-language description mutation generates no diff that typical CI tooling would flag. The June 2025 MCP spec revision added a tools/list_changed notification mechanism for client-side detection, but enforcement is client-side and inconsistent across implementations in practice.

Invariant Labs published a proof-of-concept in April 2025 demonstrating that a single poisoned tool description exfiltrated private repository contents and message histories with no user interaction. Across more than 45 real-world MCP servers in their lab benchmarking, attack success rates exceeded 60%. That is not a theoretical failure mode. It is a baseline expectation until proven otherwise.

Prompt injection via tool outputs

This class is structurally distinct from tool poisoning, and conflating them produces incomplete test coverage. Poisoning attacks the tool's definition. Indirect injection attacks the data the tool returns.

EchoLeak, CVE-2025-32711 with a CVSS score of 9.3, is the defining specimen. A single crafted email planted hidden instructions that a productivity agent later retrieved as context, causing it to exfiltrate data with no clicks and no user interaction whatsoever. The attack works because tool output occupies a region of the agent's context that users typically cannot inspect in real time. The agent sees instructions. The user sees nothing.

OWASP classifies this under ASI01: Agent Goal Hijack.

Intent drift and unauthorized tool invocation

Intent drift describes a class of multi-turn failures where no single agent action is obviously malicious, but the sequence of actions cumulatively diverges from the user's stated goal. This cannot be detected with single-turn probes. The risk manifests across multi-step sequences where individual steps pass local scrutiny.

The OWASP Top 10 for Agentic Applications 2026 addresses the authorization dimension through ASI02 (Tool Misuse and Exploitation) and ASI03 (Agent Identity and Privilege Abuse): agents invoking tools outside their sanctioned scope, or exercising privileges beyond what the task actually requires. Both require testing multi-step sequences, not isolated interactions.

Unauthenticated tool exposure at scale

A May 2026 arXiv preprint measuring 7,973 live remote MCP servers found that 40.55% of them, 3,233 servers, exposed tools with no authentication mechanism at all. Only 8.5% of MCP servers currently implement OAuth 2.1, despite it being the protocol's mandatory security standard for remote deployments.

Shadow MCP servers compound this. These are unsupervised deployments spun up by developers or research teams for experimentation, typically using default credentials or permissive configurations, operating entirely outside organizational security governance. Their existence is itself a finding. You cannot secure a surface you do not know is there.

How the OWASP and MITRE ATLAS frameworks map to these threat classes

The OWASP Top 10 for Agentic Applications 2026, published December 9, 2025, and built by more than 100 security experts and researchers, is the most directly applicable framework for MCP red teaming. It maps cleanly onto the four threat classes above.

ASI01 (Agent Goal Hijack) covers prompt injection and tool poisoning that redirect the agent's objective. ASI02 (Tool Misuse and Exploitation) covers unauthorized or out-of-scope tool invocations. ASI03 (Agent Identity and Privilege Abuse) covers agents acting with delegated authority beyond what the task warrants. ASI04 (Agentic Supply Chain Compromise) covers malicious or compromised tool and server dependencies. ASI06 (Memory and Context Poisoning) covers persistent corruption of agent state across sessions.

MITRE ATLAS serves a different but complementary function. Its taxonomy provides vocabulary that security operations teams already recognize, particularly useful when you are writing findings for an audience that does not live inside MCP-specific discourse. The ATLAS framework's MCP and Tool-Protocol Security section focuses on ASI02 and ASI04, making it the most relevant portion for the test classes covered here.

The Cloud Security Alliance's Agentic AI Red Teaming Guide addresses permission escalation, hallucination exploitation, orchestration flaws, memory manipulation, and supply chain risks with procedural depth that OWASP deliberately leaves at a higher level of abstraction.

Use these three together in a specific way. OWASP functions as the test checklist: what to test. ATLAS functions as the finding taxonomy: how to label and communicate results. The CSA guide functions as the procedural supplement: how to operationalize the steps OWASP describes at altitude. Critically, all three frameworks share one structural assumption that matters enormously: you are testing the full deployed application, including system prompt, retrieval pipeline, tools, guardrails, and agent orchestration, not the underlying model in isolation. Evaluating the model alone leaves most of the real attack surface untouched.

Reconnaissance: mapping the MCP tool surface before active testing begins

The reconnaissance phase has one non-negotiable objective: enumerate every reachable MCP server in the target environment, approved, shadow, and third-party. The gap between what IT has authorized and what is actually running is itself a finding, sometimes the most significant one in the engagement.

For each server, document four things. First, authentication posture: OAuth 2.1 with PKCE, static token, or nothing at all. Second, scope configuration: whether access scoping is implemented. A May 2026 arXiv preprint found that only 18% of MCP server deployments implement any form of access scoping, which is the baseline expectation you are working against. Third, transport type: STDIO versus streamable HTTP. STDIO carries a distinct risk profile because it enables direct configuration-to-command execution, the exact mechanism behind the OX Security disclosure. Fourth, the full tool inventory: names, descriptions, and parameter schemas for every exposed tool on every server.

Document version and update cadence for each server. Rug-pull testing requires a baseline snapshot to diff against; without it you have no way to detect description mutations between the start of the engagement and subsequent enumerations.

For large-surface environments, automated scanning is not optional. Tencent's open-source AI-Infra-Guard scanner has conducted security audits across thousands of MCP projects in major MCP marketplaces, uncovering over 4,000 instances of novel AI security risks and code implementation flaws. Tooling for this kind of enumeration exists. Use it in the recon phase, not as an afterthought.

Establish the principal hierarchy for each server: which human users and which non-human service accounts are authorized to call which tools. This is the baseline against which every privilege escalation and confused-deputy test is subsequently run.

Flag any server that uses token passthrough to upstream APIs. The June 2025 MCP spec explicitly prohibits this pattern as a source of confused-deputy vulnerabilities. Its presence during recon tells you where to focus authentication testing.

Testing tool poisoning: static schema inspection and dynamic injection probes

Static phase

Inspect every field in the tool schema: name, description, parameter names, parameter descriptions, and enum values. Not just the top-level description field. The entire schema is a potential instruction surface.

Look for four things specifically: natural language that addresses the model directly ("when the user asks you to do X, do Y instead"); conditional logic phrased as model instructions; base64 or Unicode-obfuscated content; and invisible Unicode characters used to hide instructions from human reviewers while keeping them visible to the model's tokenizer. All four patterns appear in documented real-world attacks, not just in contrived laboratory conditions.

Dynamic phase

Craft adversarial tool responses and deliver them to the agent as if they were legitimate server output. With typed tool schemas and replayable transports, you can build test fixtures that simulate adversarial inputs at tool boundaries and verify post-conditions systematically. This yields reproducible, diffable test cases for prompt injection and insecure output handling, which matters for producing findings that engineering teams can act on.

Test specifically for the GitHub MCP pattern: does the agent treat instructions embedded in tool return values as commands? Then extend that test to cross-tool injection. Does a malicious instruction embedded in Tool A's output alter the agent's behavior when it subsequently calls Tool B? Cross-tool injection is a higher-severity variant that most single-tool probes will miss entirely.

Rug-pull detection

Take a snapshot of all tool descriptions at the start of the engagement. Re-enumerate at intervals. Diff against the baseline. Then verify whether the target client implementation actually monitors tools/list_changed notifications and surfaces description changes to users or writes them to logs. Many implementations receive the notification and silently accept the updated description without alerting anyone. That behavior is itself a finding.

Tool shadowing

Test whether a malicious tool with a name or description similar to a legitimate tool can cause the agent to invoke the wrong tool. In environments with large tool catalogs, name collision and description proximity are realistic attack vectors, not edge cases.

Document success conditions precisely. What data did the agent expose? What action did it take? "Injection succeeded" is not a finding. The specific downstream consequence is.

Testing authentication gaps and the OAuth 2.1 implementation in practice

The specification mandates OAuth 2.1 with PKCE for all remote MCP servers. The May 2026 arXiv data shows 40.55% of live remote servers expose tools with no authentication at all. Test against deployed reality, not the spec.

For servers claiming OAuth 2.1 compliance, verify four things in sequence.

First, confirm that PKCE is implemented using the S256 method, not plain. The plain method is a downgrade that negates PKCE's core protection against authorization code interception.

Second, test for dynamic client registration flaws. Among the 119 OAuth servers the May 2026 arXiv preprint tested dynamically, dynamic client registration flaws affected 96.6% of them. That is the highest-prevalence vulnerability category the study identified. Treat it as the default assumption until disproved.

Third, verify resource indicators per RFC 8707. Tokens should be strictly scoped to specific MCP servers. Test whether a token issued for one server can be redeemed at another. Token mis-redemption is a straightforward test and a high-impact finding when it succeeds.

Fourth, verify that the server implements OAuth 2.0 Protected Resource Metadata per RFC 9728, and that clients use it for authorization server discovery rather than relying on hardcoded endpoints. Hardcoded endpoints are a brittle configuration that creates confusion-of-authority risks during server migrations or multi-tenant deployments.

Beyond the OAuth implementation itself: attempt token passthrough, using the MCP client's token to call an upstream API directly through the MCP server. If it succeeds, the server is implementing the confused-deputy pattern the spec explicitly prohibits.

Test DNS rebinding against STDIO-transport servers. CVE-2026-35568 in the Java SDK demonstrated that a locally or network-private MCP server can be accessed through a victim's browser, enabling tool calls as if from a locally running agent. The vulnerability is transport-specific and easy to overlook if your testing methodology focuses exclusively on remote servers.

For servers using API keys or static tokens, verify that tokens are not embedded in tool schemas, model memory, protocol logs, or debug traces. OWASP MCP01:2025 documents this as a direct path to full compromise of connected systems. Static credentials leak into telemetry and logs with a frequency that should still be surprising, but consistently is not.

Finally, test scope consent behavior. Does the client request minimum necessary scopes per operation, or does it request broad scopes upfront? Overbroad scopes do not create a vulnerability in isolation, but they dramatically increase the blast radius of any subsequent compromise.

Testing intent drift across multi-turn agent sequences

Single-turn probes are structurally insufficient for this threat class. Intent drift and unauthorized tool chaining only manifest across multi-step sequences where each individual action appears within bounds at the moment it occurs. The failure is cumulative, not atomic.

Design test sequences that give the agent a legitimate starting goal, then introduce environmental conditions that redirect it: injected context, modified tool output, or deliberately ambiguous follow-on instructions. Measure whether the agent's tool call sequence at step N+3 or N+4 still serves the original user goal or has drifted. The measurement has to be against the original goal, not against the immediately preceding step, because drift is gradual enough that each step looks locally reasonable.

Test specifically for tool invocations outside the scope of the stated task. OWASP ASI02 and ASI03 both apply here. An agent that calls a file-write tool when the user asked it to summarize a document has committed an ASI02 violation. An agent that requests administrative credentials to complete a task that does not require them has committed an ASI03 violation. Both require multi-step sequences to elicit reliably.

Run privilege escalation sequences: test whether an agent can be prompted to request or exercise permissions beyond what the current task requires, and test whether it retains elevated permissions across session boundaries. Session boundary persistence is particularly important in deployments where agents share memory infrastructure.

In multi-agent environments, test cascading failure scenarios under OWASP ASI08. Can a compromised agent issue instructions to a downstream agent that exceed the original user's authorization? The blast radius of a single compromised agent in an orchestrated pipeline is much larger than its individual permission set suggests, because it can delegate upward or laterally to agents with broader access.

Test memory and context poisoning explicitly. An agent that retains poisoned context across sessions carries a vulnerability that persists beyond the interaction in which the attack was introduced. Plant adversarial content in a session, end the session, start a new one, and verify whether the corrupted context influences subsequent behavior. If it does, the attack surface extends beyond the current conversation and into every future interaction the agent has with any user who shares that memory store.