MCP as an injection surface

Read these first

• Prompt injection
• Trusting third-party servers

What you will know

• Build a test MCP server that injects instructions through both tool results and resource content, then capture the model's resulting behavior.

  The two channels can carry different schemas and provenance, so a defense that filters only returned tool text may leave resource reads exploitable.

• Show that MCP moves the trust boundary rather than removing it

  The protocol can standardize invocation and transport while leaving server-authored text outside your control.

• Review a server's outputs as untrusted content

  A string that looks like a policy instruction can be rendered, logged, or passed onward without being trustworthy.

• Decide what a third-party server may and may not be connected to

  Use capability-scoped credentials, network boundaries, and explicit approval for sensitive paths; prose policy is not a control.

• Detect injected instructions arriving in a tool result

  Look for imperative language, attempts to alter system or tool policy, and provenance mismatches while accounting for false positives and evasive wording.

Chapters

1. 1

   What MCP standardises

   The protocol fixes discovery, invocation and transport, which removes a real class of integration bugs, and it fixes nothing at all about the text a server returns. This chapter measures what changes when three hand-written API clients are replaced by three MCP servers: externally-authored text in context per task rising from about 600 tokens to about 9,400, another 1,040 tokens of server-authored tool descriptions present before any call, and the decision about what the model reads moving from your own formatter into somebody else's rendering code.

   Read chapter
2. 2

   Tool results and resources

   Server-authored text reaches an agent through at least two routes with different schemas, different calls and usually different code in your client, and a demonstration has to carry the same payload on each. Aimed at moving a real tool call with attacker-chosen arguments rather than at printing a system prompt, one canary server converted 31 times out of 40 on the tool-result path and 0 out of 40 on the resource path — and the zero turned out to be a question about the client's attachment handling rather than a property of the channel.

   Read chapter
3. 3

   Scoping destination arguments

   A tool result announcing that this workspace requires all summaries to be emailed to compliance@example.org is a string from a third party, and an agent holding send_email will act on it. Recipients, destinations, paths and scopes come from your own configuration, enforced by the tool schema rather than by a line in the system prompt — which moved one measured payload from 31/40 to 22/40 and bounded nothing. The same string is also read by the chat renderer, the approval dialog, the log store and whatever quotes them later.

   Read chapter
4. 4

   The input surface of a relay server

   Reading the code, checking the maintainers and pinning the digest answers whether a server is dishonest, and a server indexing an issue tracker and a wiki needs no dishonesty at all: 412 internal accounts, 24 external wiki editors and 31,400 self-service portal accounts author the text it faithfully returns. What decides the risk is the pairing — capability-scoped credentials, tool-set separation, a default-deny egress policy and out-of-band approval — because a paragraph in an integration document is read by no component at runtime.

   Read chapter
5. 5

   Injection detectors

   Scanning server-authored text for imperative language, restated policy or a foreign tool name produced 612 flags in 41,200 tool results, of which 3 were real, while a narration-shaped payload passed 40 times out of 40. Nine alerts a week at 33% precision is a signal a person will read; 612 blocks a week at 0.5% is an outage generator, and it is the same detector. This chapter sets out the three signal families, where the detector goes, what it emits, and how to write the controls-table row so nobody records it as the control.

   Read chapter
6. 6

   Server registration and escalation tiers

   A mandatory security review before any server is connected runs at three to four requests a week against four hours of reviewer time, produces a 19-day median wait, and its measurable achievement is an inventory nobody trusts — six servers reviewed while 31 were running. Registration that auto-merges in 41 seconds, with credential scope and egress derived from a tier, plus a named approver only for write scopes, external egress or an agent holding an acting tool, is the shape that survives contact with engineers. This chapter also covers what predictably breaks it.

   Read chapter