Why your MCP server needs a red team

Tool descriptions in MCP are trusted metadata. An LLM client receives them at connection time and folds them into the system context without sanitization. A hidden directive in a description field – an HTML comment, a zero-width character sequence, an instruction addressed to the model – executes inside the agent’s own reasoning loop, where no firewall sits.

That is one finding from one engagement category. There are seven.

What a boundary engagement covers

An agent boundary engagement tests the surface between an AI agent and the systems it touches. The seven categories map to the ways that surface fails:

• Tool poisoning. Descriptions, schemas and default values that carry hidden instructions.
• Tool misuse. Functions that reach internal networks, cloud metadata endpoints or credential stores without validation.
• Identity and privilege. Missing authentication, leaked tokens, hardcoded credentials exposed through debug surfaces.
• Memory and context poisoning. Note storage, retrieval-augmented generation and conversation history that accept and replay injected payloads.
• Excessive agency. Shell execution without allowlists, file access without path validation, actions the agent can take that no human approved.
• Data leakage. Responses that carry internal state, environment variables or user data across trust boundaries.
• Governance gaps. Missing audit trails, no human-in-the-loop gates, no way to know what the agent did after the fact.

Each finding names the technique (MITRE ATLAS), the risk (OWASP LLM Top 10) and the governance control (NIST AI RMF) so the report answers the question procurement already asks.

What a unit test will not find

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

These are boundary failures, not logic failures. They live in the gaps between components, where the author of each component assumed the other side would enforce the constraint. An adversarial test finds them because it asks the question the author did not think to ask.

What you get back

Every finding ships with a regression scenario written as machine-readable YAML your engineers run in CI. A fix stays fixed when a prompt changes, a model upgrades or a tool description is edited. The report is the snapshot; the harness is the asset.

If you are shipping an MCP server, an LLM-powered agent or any system where an AI model calls tools on behalf of a user, book a scoping call and we will tell you what we would test and what it costs before you commit to anything.