Stop treating Model Context Protocol (MCP) security like it is just another API gateway problem. If you are only checking OAuth tokens, transport encryption, and session hijacking, you are missing the kill shot. The core vulnerability in MCP agents isn't the server layer; it is the model layer. Your agent reads tool descriptions like instructions, and if those descriptions are poisoned, your agent obeys the attacker, not the user.

The Blind Spot in Server-Layer Testing

Most current MCP security testing focuses on the server layer: confused deputy problems, token passthrough, SSRF, and scope minimization. These are identity and infrastructure checks. They are necessary, but they are insufficient. They do not test whether your agent will follow a hidden instruction planted in a tool's description or a changed tool's output. The model layer is where the actual execution happens, and it is where most teams have a massive blind spot.

Four Attack Vectors You Must Test

You need to run four specific attacks against your staging environment. First, tool poisoning: plant hidden instructions in the tool description itself. Second, rug pulls: swap a clean tool for a poisoned one after the user has already approved it. Third, tool shadowing: use one malicious server to alter how the agent interacts with a trusted server. Invariant Labs demonstrated this with a malicious 'add numbers' server that never even needed to be called; its description simply set rules for how the agent should use a trusted email tool, forcing every message to BCC the attacker. Fourth, poisoned tool outputs. The tool itself is honest, but the data it returns contains the injection. Invariant Labs showed that the official GitHub MCP server could be hijacked by a prompt injection hidden in a public GitHub issue, leading the agent to leak data from private repositories. If your agent trusts the output of a tool without sanitizing it for instruction-following, you are leaking data.

The 7-Step Red Team Process

Run everything in staging with fake data. Never test against production credentials. First, map every server and tool, looking for unlisted 'shadow' integrations. Second, record a baseline hash of each tool's definition. Third, plant poisoned descriptions in a test server. Fourth, simulate a rug pull by swapping tools. Fifth, test cross-server shadowing by connecting a malicious server with trusted ones and running ordinary tasks. Sixth, inject instructions into tool outputs, such as making a support ticket or web page return hidden commands. Finally, score every run and automate it in your CI/CD pipeline. Define clear pass/fail policies, such as 'fail if the agent calls any tool the task did not need.' Track the attack success rate per attack type. If you are using third-party community servers, start with tool poisoning. If you have multiple servers on one agent, prioritize shadowing. If your agent moves money or sends messages, run all four before launch.

Key Takeaways

  • Server-layer checks (OAuth, SSRF) do not protect against model-layer instruction injection.
  • Tool shadowing allows a malicious server to hijack actions on a trusted server without being called directly.
  • Prompt injections in tool outputs (like GitHub issues) can exfiltrate private data.
  • Red teaming must be automated in CI/CD because tool descriptions and models change frequently.

The Bottom Line

Your MCP agent is only as secure as its ability to ignore malicious context. If you aren't actively poisoning your tool descriptions and outputs in staging, you are just waiting for someone else to do it in production.