Red Teaming MCP-Connected Enterprise Agents

MCP red teaming isn't application security testing with a new acronym stapled on. It's a different discipline, because the thing you're testing isn't a fixed API surface, it's a language model making live decisions about which tools to call and why. I've spent enough time inside these engagements to know that the standard playbook, the one built for firewalls and auth tokens and static code paths, misses most of what actually goes wrong here.

Here's the shape of the problem. MCP runs on a three-tier setup: a host app embeds a client, the client talks to external MCP servers over JSON-RPC 2.0, and those servers expose tools, resources, and prompts back to the agent. That's the whole protocol, and on paper it looks tame. But the inversion buried inside it changes everything. A traditional client calls a known API in a predictable way. An MCP-connected agent reasons over natural-language tool descriptions and decides, on its own, what to call and when. The attack surface isn't the wire protocol anymore. It's the entire decision chain sitting behind it.

That breaks a lot of assumptions your security team probably still holds. Firewall rules and auth tokens govern the transport layer just fine, but they have nothing to say about the reasoning layer. A perfectly authenticated agent can still be talked into bypassing its own controls, because nobody hacked the connection, they just wrote a sentence the model believed. Static analysis and DAST tools can't see any of this either. They check code paths and known vulnerability patterns; they have zero visibility into what an agent chooses to do with a tool it's already allowed to use.

And the scale here is not small. Public MCP servers went from basically nothing in late 2024 to tens of thousands in about a year and a half. Every one of those is a potential connection point for an enterprise agent, and governance never caught up. Early spec versions marked MCP authorization as optional, not required, and a scan of the public internet in mid-2025 found a real number of MCP instances just sitting there, answering unauthenticated requests. Nobody locked the door because the spec didn't say you had to.

So red teaming this stuff means working three layers at once: model behavior, agent decision-making, and the MCP connections themselves. Skip one and the other two won't catch what falls through.

The threat classes that MCP introduces and that red teamers must be able to reproduce

Tool poisoning works because of a gap most people don't think about: tool descriptions get read by the model, but the user never sees them in the UI. Hide an instruction inside a description and it's invisible to the human, fully readable to the agent. Invariant Labs proved this out in April 2025 with a fake trivia-game MCP server that embedded instructions targeting a legitimate WhatsApp MCP server running in the same session. The agent pulled message history and shipped it out through traffic that looked completely trusted. Research scanning thousands of live MCP servers found 7.2% carry general security flaws, and 5.5% show this specific tool-poisoning pattern. Small percentages, sure, but multiply that against 15,000 servers and the number stops looking small. And it's genuinely hard to catch, because the poisoning lives in metadata, not in network traffic or code paths any conventional scanner is built to inspect.

Rug pulls are a related but distinct problem. MCP has no built-in way to detect when a tool's definition changes, and no way to check that a tool's current behavior still matches what got approved earlier. A server can quietly swap out a tool's definition after a session has already approved it, and nothing forces a re-approval. For red teamers, this means checking a tool once at approval time isn't enough. You have to re-verify behavior at call time, every time.

Indirect prompt injection is the one that scales the worst. An attacker embeds instructions in a document, an email, a web page, or tool output. The agent reads it as content, but treats it as instruction. EchoLeak (CVE-2025-32711) showed exactly how far this goes at enterprise scale: a hidden injection buried in a Microsoft 365 Copilot email triggered a data exfiltration over outbound HTTP, no large file transfer, nothing that tripped DLP. OWASP's Top 10 for Agentic Applications 2026 now classifies this as ASI01, Agent Goal Hijack, reviewed by NIST, Microsoft's AI Red Team, and AWS. What makes it dangerous isn't just the injection itself. It's that the data leaves wrapped in conversation-shaped output, the kind of thing DLP tools were never tuned to look for.

Cross-agent trust exploitation shows up once you've got multiple agents talking to each other. A compromised research agent can slip hidden instructions into output that a downstream financial or ops agent then consumes and trusts. Watch for agent impersonation, session smuggling, and unauthorized capability escalation across those boundaries. The Step Finance incident in early 2026 is the clearest real-world example so far: AI trading agents executed a large volume of unauthorized transfers after attackers compromised upstream context. The agents weren't malfunctioning. They did exactly what they were built to do, with corrupted inputs.

Supply chain attacks are the quiet ones. Some MCP servers are built from the start to look protocol-compliant while quietly exfiltrating data or escalating privilege. One pattern that's shown up: a fake npm package mimicking a legitimate email integration that silently copied every outbound message to an attacker-controlled address. These work because people extend trust to anything that looks like a proper MCP server, without checking further.

SSRF and code execution round out the list, and this is where MCP starts looking like classic infrastructure security again. Tool-supplied URLs with no egress allowlist and no scheme validation can route agent requests to internal endpoints or cloud metadata services. CVE-2025-53967 in Figma's MCP server allowed remote code execution through command injection. CVE-2025-49596, a critical RCE, hit Anthropic's own MCP Inspector. By mid-2026, the Cloud Security Alliance had counted at least 7 confirmed high- or critical-severity CVEs across major MCP-integrated platforms, including MCP Inspector, LiteLLM, Cursor, LibreChat, and Windsurf.

What the attack success data says about agent defenses before red teaming begins

NIST's red team work found something worth sitting with: novel attack techniques aimed at AI agents hit task-hijacking success rates roughly 7 times higher than the strongest known baseline attacks. Offense is outrunning defenses built around known attack taxonomies, and that gap is the whole reason MCP red teaming has to exist as its own thing.

Model-layer refusals aren't much of a control here. Multi-turn attacks that stretch out across a long conversation hit high success rates against open-weight models in 2025 testing. Agents almost never refuse these outright, and that makes sense once you think about it: safety alignment is tuned to catch requests for disallowed content, not an agent using a legitimate tool for an unauthorized purpose. Nobody asked the model to do anything forbidden. They just asked it to use a tool it already had permission to use, in a context it misjudged.

Then there's the non-determinism problem, and this one trips up a lot of testing programs before they even start. Agents don't produce the same output twice. A probe that fails on attempt one can succeed on attempt three. Research modeling multiple attempts per task, instead of single-shot evaluation, showed attack success rates climb substantially once you account for retries. So a single-shot test that comes back clean tells you almost nothing about what a patient attacker with a dozen tries would find.

Put together, this means most enterprises that call a deployed agent "safe" tested it under conditions a lot friendlier than any real attacker would agree to. And the layers compound: test only the model, or only agent behavior, or only the MCP connections, and you'll miss the attacks that live in the seams between them. That's where the real damage tends to happen.

How to structure an MCP red team engagement before any probes run

Map the surface first. Write nothing yet.

Enumerate every MCP server the agent touches: name, version, transport type (stdio or HTTP), and whether it's local, remote, or sitting behind a proxy. For each one, document the tools it exposes, the resources it can read, and what real systems those tools reach downstream. Then figure out the trust relationships. Which servers does the agent treat as authoritative, and is that assumption written into the system prompt, or just assumed?

Audit authentication next, server by server. Check whether OAuth 2.1 is actually implemented, or whether the server just accepts unauthenticated connections, which the mid-2025 scan found happening on a meaningful chunk of public MCP instances. Verify PKCE and Resource Indicators (RFC 8707) are in use on HTTP transports, per current spec. And flag any OAuth proxy sitting in the chain: CVE-2025-6514 in mcp-remote showed that a booby-trapped authorization_endpoint from a malicious server can compromise the proxy itself, not just the connection it's brokering.

From there, build the threat model specific to this agent, not a generic one. Who can author content this agent will eventually read, email senders, document editors, support ticket submitters? All of those are indirect injection surfaces. Which tools carry credentials, or can take actions with financial or data consequences? Does this agent talk to other agents? If so, every one of those boundaries is a trust assumption that needs its own test.

Set up logging before any of this starts, not after. Tamper-proof audit logs and OTEL tracing aren't nice-to-haves you bolt on post-engagement; without them, multi-step attacks spanning several tool calls are nearly impossible to reconstruct afterward. And establish a real baseline of normal agent behavior across representative tasks first, so drift during your probe scenarios is something you can measure, not just something that feels off.

Probing tool poisoning and rug pull vulnerabilities in practice

Start by reading every tool description the agent will actually consume, not just the ones the UI happens to display. Look for hidden instructions using whitespace tricks, Unicode homoglyphs, or text tucked in after what looks like a normal description paragraph. Check whether any description references other tools in the session; that cross-tool embedding is exactly the pattern Invariant Labs exploited.

Then build your own poisoned server for the engagement. Stand up something that looks like a legitimate integration, a calendar tool, a file reader, a search connector, and quietly embed instructions targeting a high-value tool in the same session. Test whether the agent follows the buried instruction, whether it tells the user it did anything, and whether the output routes back out through the trusted server. Vary where you place the payload too: tool description, resource response, prompt template. Susceptibility often differs by channel, and you won't know which channel matters until you test all of them.

For rug pulls, get the agent to approve a tool, then change that tool's definition server-side and watch what happens on the next call. Does the client catch the change, or proceed like nothing happened? If the agent caches tool definitions at all, check whether that cache ever gets invalidated, or whether a poisoned definition just sits there persisting across sessions.

What you find here should map straight to real controls. Tool description integrity checking and cryptographic tool identity verification, the approach proposed in the ETDI extension to MCP, exist specifically to address this. Your findings tell you whether those controls are missing entirely, present but easy to walk around, or actually enforced at call time.

Running indirect prompt injection probes across every data surface the agent reads

The injection surface is everything the agent reads, full stop, not just what the user types into the chat box. That includes email bodies and attachments, the EchoLeak vector. Documents pulled in through MCP resource calls. Web pages fetched by a browsing tool. Raw output returned by a connected server. Support tickets, calendar entries, database records, anything the agent ingests as context is fair game.

For each of those surfaces, craft a payload that pushes the agent toward one specific unauthorized action, pulling a credential, calling a tool it shouldn't touch, summarizing sensitive data out to an external endpoint, and embed it inside content a normal user would plausibly send. Vary the encoding and the phrasing to soften model-layer filtering. And test escalation across turns: start with something that reads as harmless, then follow up with a second instruction that pushes further, since extended conversations showed meaningfully higher success rates than single-shot attempts in testing.

Semantic exfiltration deserves its own pass. Check whether the agent can be steered into slipping sensitive data into outputs that would never trip a DLP rule: a conversation summary, a formatted response, the parameters of a tool call. EchoLeak got its data out through outbound HTTP requests the agent itself generated, so test whether injected content can redirect the agent's own tool calls toward an address the attacker controls.

What comes out of this should shape three things directly: system prompts built to resist injection, output filters that inspect tool call parameters and not just the chat response, and content inspection applied to what the agent retrieves, not only what the user types in.

Testing authentication, credential handling, and privilege boundaries across MCP connections

Start with an inventory. List every credential, token, and OAuth scope the agent can reach across every connected MCP server. Then separate the tools that call out using standing credentials from the ones that request credentials fresh at call time; standing credentials are the higher-value target for anyone trying to exfiltrate access through an injection.

Try connecting to each MCP server with no credentials at all and document what comes back. Check whether the OAuth setup validates token audience under Resource Indicators (RFC 8707), because token passthrough attacks specifically target servers that accept tokens meant for somewhere else. And wherever an OAuth proxy sits in the chain, test whether a malicious authorization_endpoint response can hijack token issuance.

Then push on privilege boundaries directly. Try calling tools with scopes the agent's credential shouldn't cover, and note whether the server enforces scope at the tool level or only checks it once, at connection time. In multi-agent setups, test whether one agent can assert another's identity, or quietly inherit its permissions without any explicit delegation happening. And run SSRF checks on every tool connector: feed in URLs pointing at internal network ranges or cloud metadata endpoints and watch whether the server actually goes and fetches them.

The credential exfiltration piece ties everything above together, because it's the one place tool poisoning, prompt injection, and weak scope enforcement can chain into a single incident, an agent injected with instructions, holding a standing credential, calling a tool with no scope check on the other end. That chain is exactly what a real attacker builds toward, and it's exactly what a probe testing only one layer at a time will never catch.