Why MCP Servers Need Red Teaming: A Breakdown of Seven Boundary Attack Surfaces

MCP (Model Context Protocol) is becoming the de facto standard for AI Agents to call external tools. But one overlooked fact is this: the attack surface exposed by MCP servers is far more insidious than that of traditional APIs—because its core interaction medium is natural language itself.

Tool Descriptions: A Trust Chain Never Covered by Firewalls

In the MCP protocol, tool descriptions are treated as trusted metadata. When an LLM client establishes a connection, it receives these descriptions, performs no sanitization whatsoever, and folds them directly into the system context.

This means a hidden instruction buried in a description field—an HTML comment, a string of zero-width characters, a sentence written directly to the model—will execute within the Agent's own reasoning loop. Firewalls, WAFs, and input filters in traditional security architectures all fail at this position.

This is not theoretical speculation. The security team Stonepath IT listed it as one of seven major categories of findings in Agent boundary testing in a technical analysis, and pointed out that the attack surface behind it extends far beyond this.

Model Context Protocol (MCP) is a communication protocol open-sourced by Anthropic in late 2024, designed to let LLM applications connect to external data sources and tools in a unified way. It uses a client-server architecture: the MCP Host (such as Claude Desktop or IDE plugins) establishes connections with MCP Servers through MCP Clients, and Servers expose three types of capabilities outward—Tools (invocable functions), Resources (readable data), and Prompts (preset templates).

Unlike traditional interface description specifications such as OpenAPI, MCP Servers actively push the tool list and description text to Clients during the handshake phase, and this content is subsequently serialized into the model's system prompt. In other words, MCP hands the step of "advertising what capabilities it has" to the model to read, rather than to human developers. This design greatly lowers the integration threshold, but it also turns the description field into "semi-trusted code" that attackers can write and models will execute.

System context refers to the high-priority content injected into the model's context window before a conversation begins, typically including system prompts, tool definitions, role settings, and so on. It is invisible to users, yet the model treats it as "highest instructions." When MCP tool descriptions are folded into the system context, attackers effectively gain a channel to write into the system prompt with elevated privileges—this is precisely the most destructive variant of prompt injection in Agent scenarios: the attack payload does not need to deceive the user, only to deceive the tool registration process once.

Seven Categories of Boundary Failures

Stonepath IT's "Agent boundary assessment" tests the interface between an AI Agent and the systems it touches. The seven categories of findings correspond to seven ways of failing:

Tool Poisoning—hidden instructions embedded in descriptions, schemas, and default values. This is the most easily underestimated category because it exploits the trust assumptions built into the protocol's own design.

Tool Misuse—functions can access internal networks, cloud metadata endpoints (such as 169.254.169.254), or credential stores without validation. A seemingly harmless fetch_url tool in CLAUDE.md can become an entry point for SSRF.

Identity and Privilege—missing authentication, token leakage, hard-coded credentials exposed through debugging interfaces.

Memory and Context Poisoning—note stores, RAG retrieval, and conversation history accept and replay injected payloads.

Excessive Agency—shell execution without allowlists, file access without path validation, operations the Agent can take without human approval.

Data Leakage—responses carrying internal state, environment variables, or user data across trust boundaries.

Governance Gaps—lack of audit trails, absence of human-in-the-loop checkpoints, inability to reconstruct after the fact what the Agent did.

Each category of findings is simultaneously tagged with MITRE ATLAS technique IDs, OWASP LLM Top 10 risk classifications, and NIST AI RMF governance controls—this cross-mapping of three frameworks happens to be exactly what is most frequently questioned during procurement and security review.

What Unit Tests Cannot Find

A unit test asserts that a function returns the correct value given the correct input. It does not assert that a tool description contains no prompt injection, does not assert that fetch_url("http://169.254.169.254/latest/meta-data/") is blocked, and does not assert that run_command("env | grep TOKEN") refuses to execute.

These are boundary failures, not logic failures. They exist in the gaps between components—each component's author assumes the other will enforce constraints. Adversarial testing can find them because it asks questions the authors did not think to ask.

This distinction is important for engineering teams: boundary testing is not "more unit tests," but rather requires a different mental model. The person writing the tests needs to think like an attacker, not like a verifier.

Making Remediation an Asset: From Reports to CI Pipelines

Stonepath IT's approach is worth noting: each finding comes with a machine-readable YAML regression scenario that engineers can run directly in CI.

The value of this design is that when prompts change, models are upgraded, or tool descriptions are edited, the remediation does not silently fail. A report is only a snapshot; a testing framework is an asset.

For those delivering MCP servers, LLM-driven Agents, or any system in which an AI model calls tools on behalf of a user, this approach provides an actionable starting point—not doing a penetration test once and archiving the report, but turning security into an engineering practice that can be continuously verified.

Who Should Pay Attention to This

If you are building any of the following types of systems, boundary assessment should be included in the release process:

• MCP servers or server-side services for similar tool-calling protocols
• LLM applications using function calling
• Any system in which an Agent can autonomously perform operations

The core criterion is simple: when an AI model calls tools on behalf of a user, have the trust assumptions between components been adversarially verified? If not, then a line of hidden instructions in a tool description, an unvalidated URL parameter, or an over-authorized shell call can all become a breakthrough point.

Security boundaries do not automatically exist just because no one tests them.

Background Supplement

SSRF (Server-Side Request Forgery) is a vulnerability that causes a server to initiate network requests on behalf of an attacker. In traditional Web scenarios, attackers manipulate URL parameters to make the backend access internal services; in Agent scenarios, the trigger point becomes the tool's call parameters. The cloud environment metadata endpoint 169.254.169.254 is a classic SSRF target—it can return sensitive information such as an instance's temporary IAM credentials and user data scripts without authentication. Once an Agent's fetch_url-type tool lacks an address allowlist or private network range blocking, the model may be induced to "read this URL," thereby spitting cloud account credentials back into the conversation verbatim.

These three frameworks have different roles: MITRE ATLAS is a knowledge base of attack techniques and tactics against AI systems, analogous to ATT&CK in traditional security, answering "how attackers do it"; OWASP LLM Top 10 is an application-layer risk list, answering "what is most likely to go wrong," such as LLM01 Prompt Injection and LLM06 Excessive Agency; NIST AI RMF is a governance and process framework, answering "how organizations should manage risk," with its four functions Govern/Map/Measure/Manage corresponding to governance actions. Mapping a single test finding to all three at once means the same piece of evidence can be used by engineers to reproduce the vulnerability, by security teams to rate it, and by compliance and procurement departments to benchmark controls—this is the key to making vulnerability reports actually drive organizational action.

One-line Summary

MCP tool descriptions send hidden instructions directly into the LLM system context, and Agent boundary assessment must cover seven categories of adversarial failures.

Paragraph Summary

The article points out that MCP tool descriptions are treated as trusted metadata and folded directly into the LLM's system context, where hidden instructions execute within the Agent's reasoning loop, and traditional firewalls and WAFs are completely ineffective here. The security team Stonepath IT's Agent boundary assessment presents seven categories of failure: tool poisoning, tool misuse, identity and privilege, memory and context poisoning, excessive agency, data leakage, and governance gaps, each mapped simultaneously to MITRE ATLAS, OWASP LLM Top 10, and NIST AI RMF. The article emphasizes that these are boundary failures in the gaps between components' trust assumptions, which unit tests cannot cover and which require adversarial thinking. The remediation approach is then turned into an asset—each finding comes with a readable YAML regression scenario run in CI, turning security from a one-time report into a continuously verifiable engineering practice.