Protect MCP From Prompt Injection and Excessive Agency

MCP's most dangerous risks appear not in the protocol but at the junction of untrusted text and real rights. A resource may try to steer the model, another server's tool description may be malicious, and an overly wide handler turns a single reasoning error into an incident. What all these threats share is one thing: the model here is not the point where security decisions are made.

It helps to keep a map of the threats in view - and what separates a naive defense from a professional one.

Threat · Naive · Professional control

• Prompt injection in a resource - Insert the text as a system prompt; Mark it as data, keep provenance, limit the instruction hierarchy
• Tool poisoning - Trust the description of any server; Allowlist servers, review manifests, show origin
• Excessive agency - execute_shell; Narrow capabilities, sandbox, approval, allowlist
• Tenant leak - A filter only in the model prompt; Object-level authorization in the repository
• SSRF - The server fetches an arbitrary URL; A URL policy, DNS/IP checks, an egress proxy
• Secret exfiltration - Returning env/tool errors to the model; Redaction and a minimal result
• Replay side effect - Repeat after a timeout; An idempotency key and reconciliation

Read it by the "professional control" column: almost everywhere the defense is not an instruction to the model but code and infrastructure. Prompt injection in a resource is cured by marking it data and provenance, not by trusting the text. Tool poisoning - an allowlist of servers and a review of manifests. Excessive agency - narrow capabilities, a sandbox, and approval instead of execute_shell. Tenant leak - object-level authorization in the repository, not a filter in the model prompt.

Folding this into one safe handler pipeline is helped by this sequence.

Two principles are worth pulling out separately, because they're stumbled over most often.

The model is not a policy enforcement point. The phrase "don't read other people's data" in a prompt is useful but doesn't replace WHERE tenant_id = actor.tenantId, ACLs, and an approval service. Rights are checked by code, not by coaxing.

Separate read, preview, and commit. The model loop may read and prepare a preview. Commit is better done by a separate trusted endpoint after the user has precisely confirmed the parameters - then a model error doesn't become an irreversible action.

The server is written, defended, and authorized. What's left is to prove it works - and to release it in a way that can be reproduced.