The trust model: consent, annotations, and code you run

Lesson 4 of 5 in MCP Fundamentals: One Protocol Instead of M × N Integrations.

MCP has a security section, and it is unusually honest about its own limits. It states principles, then says the protocol cannot enforce them.

That sentence deserves to land before you read the principles: MCP is a wire protocol, not a security boundary. Every guarantee your deployment has, your host and your operations provide.

MCP Specification 2026-07-28 — Security and Trust & Safety

Key principles from the spec:

Users must explicitly consent to and understand all data access and operations.
Hosts must obtain explicit user consent before exposing user data to servers, and before invoking any tool.
Tools represent arbitrary code execution — so tool descriptions and annotations should be considered untrusted unless obtained from a trusted server.

And the caveat the spec itself adds: MCP cannot enforce these principles at the protocol level. Implementors SHOULD build consent and authorization flows, document security implications, and implement access controls.

The tools page adds that although tools are model-controlled, “there SHOULD always be a human in the loop with the ability to deny tool invocations” — with clear UI showing which tools are exposed, visual indicators on invocation, and confirmation prompts. The protocol does not mandate a specific interaction model.

Installing an MCP server is a decision to run someone’s code

A stdio server is a program the client launches on your machine, with your user’s privileges. Not a plugin in a sandbox, not a config file — a process. It can read whatever your user can read, and it inherits the environment variables you handed it, which is where the authorization spec says stdio credentials come from.

So npx some-mcp-server is the same class of decision as npm install on a package with a postinstall script — plus a language model that can be talked into calling its tools. A malicious or compromised server needs no exploit: it just has to be installed, and then describe its tools persuasively.

This is why the least-privilege questions come first — which directory, which token, which scopes — and why the supply chain view of MCP is a security topic in its own right. Crosswalk: security/supply-chain-and-mcp-security.

The second trap is subtler, and it catches sophisticated teams: tool annotations are hints, not guarantees.

Annotations arrived in revision 2025-03-26 as behaviour descriptions — whether a tool is read-only or destructive, for instance — so hosts could render better UI and apply better policy. They are genuinely useful. They are also self-reported by the server.

Who can actually enforce what
Control	What it can do	What it cannot do	Where the real enforcement lives
Tool annotations (readOnly, destructive…)	Let a host colour-code actions, auto-approve safe classes, and require confirmation for risky ones.	Prevent a lying server from marking a deleting tool read-only.	Host policy plus the permissions actually granted to the server.
Tool descriptions	Tell the model when a tool is appropriate — the difference between a used tool and an ignored one.	Be trusted. They are attacker-controlled text that enters your model’s context: prime injection territory.	Reviewing servers before install; pinning versions; watching for description changes.
The host consent prompt	Stop an invocation before it happens — the one place a human can say no.	Survive habituation. A prompt that always says yes trains the click, not the judgement.	Gating a small set of genuinely consequential actions, and measuring how fast people approve.
MCP authorization (OAuth 2.1-based)	Bind tokens to a specific audience so a server cannot replay yours elsewhere; carry scopes.	Be assumed present — authorization is OPTIONAL in MCP and defined for HTTP transports only.	Your deployment: mandate it for remote servers, scope tokens narrowly, and validate audience server-side.
The 1:1 client/server isolation	Keep conversation history with the host and stop one server from seeing into another.	Stop exfiltration through the model — a server whose output steers the agent into calling another server’s tool.	Egress control, approval gates on writes, and not co-locating a private-data server with an untrusted one.

Should this MCP server go on this machine?

Interactive decision tree — outcomes:

Reasonable to install
Known maintainer, narrow scope, no outbound side effects. Still pin the version, still keep the tool list under review — a benign server can change hands, and tool descriptions are part of your prompt.
Install, but gate the writes
Side effects need the human-in-the-loop the tools spec asks for: confirmation on the consequential calls, visible arguments, and an audit trail. Gate the few actions that matter rather than everything, or habituation will hollow out the gate you needed.
Stop — this is the lethal trifecta
Private data access, exposure to untrusted content, and an outbound channel in one session is the lethal trifecta. Injected text in a page or ticket can steer the model into using your legitimate tools to exfiltrate. Break one leg: split the session, remove the egress tool, or put an approval gate on every outbound call. The security domain works this through properly.
Narrow the grant first
Do not install against your home directory or an admin token because that is what the README example used. Point it at one project directory, mint a token with the minimum scopes, and prefer a container or a dedicated account. Least privilege is the only control here that does not depend on the server behaving.
Unknown provenance — treat as untrusted code
Annotations and descriptions from an unknown server are untrusted by spec. If you must try it, read the source, run it in a container with no credentials and no network, and give it nothing you would mind losing. “It was on the internet and had stars” is not provenance.

Key terms: tool annotations, least privilege, prompt injection, lethal trifecta, human-in-the-loop, approval gate, supply chain

Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.