MCP Trust Boundaries — Diagram
Where the trust boundaries actually fall in a Model Context Protocol setup — what the model can influence, what a server can influence, and the two places content becomes action.
SVG. No sign-up, no email.
Diagrams of the Model Context Protocol usually show a client, a server and a happy arrow between them. That is the plumbing. What matters for security is where the trust boundaries fall, and there are more of them than the architecture suggests.
Two things in the picture below are frequently missed: tool descriptions reach the model as prompt content, and tool responses can contain text written by someone else entirely.
Reading the middle lane#
The middle lane has no arrows deliberately. These are not a sequence — they are three independent channels through which text you did not write arrives in the model's context. Any one of them can carry an instruction.
Tool descriptions are the surprising one. When a client connects to a server, the tool descriptions are injected into the model's context so it knows what is available. A server author — careless or hostile — can phrase a description as guidance: always call this before answering. That is prompt content authored by a third party, and it is present on every request.
Tool responses carry whatever the target system returns, which may include text from a customer, a web page or a document.
Retrieved resources are the case most teams already think about.
The two boundaries that matter#
Content → model. Everything in the middle lane crosses it. The mitigation is to treat all of it as data: delimit it, state that it is not instruction, and do not let it silently expand what the model believes it should do.
Model → effect. The right-hand lane. This is where a decision becomes something that happened. The controls here are the ones that actually bound the damage: narrow tools rather than broad ones, the server's own scoped credentials, and confirmation on anything irreversible.
The combination to avoid#
Reads untrusted content and holds a consequential tool and acts without confirmation.
Any two of those three is manageable. All three together means a document can cause an action. Break one of them — usually the third, because it is the cheapest.
What the diagram does not show#
Rate and spend limits, which sit outside everything here and must be enforced by the layer running the client. An agent can reason its way past its own instructions; it cannot reason past a supervisor that refuses the next call.
See MCP for the wider picture, the server review checklist before connecting one, and AI agents for the bounded-autonomy discipline.