When I built agent tooling over MCP into a self-hosted AI platform, getting a tool to work was the easy part. Making it safe to point at real systems was the real work, and it's the part most MCP demos skip.
The Model Context Protocol has become the default way to connect agents to tools and data. The protocol now carries serious security guidance of its own12. Below is the checklist I use, grouped the way I review a design: identity, authorisation, the tools themselves, the model's inputs, and operations.
Why MCP changes the threat model
A chatbot that can only talk has a limited blast radius. An agent with MCP tools can read files, query databases, open tickets and call internal APIs, and it decides when to do so based on text it has read. That text can come from a user, a document or a web page, and any of them can contain instructions.
So the question shifts from "what can the model say?" to "what can the model do, on whose authority, and how would we know?". OWASP's list of LLM risks reflects this, with prompt injection and excessive agency near the top5.
1. Tokens: audience is everything
The most important rule in the MCP guidance is short. MCP servers must not accept tokens that were not explicitly issued for them1, and must validate that a presented token was issued for their use2.
- Validate the audience on every request. A token minted for your CRM API is not a token for your MCP server, even if both trust the same identity provider.
- Clients request audience-bound tokens. MCP clients include the resource parameter defined in RFC 8707 so each token is bound to one server23.
- Never pass tokens through. If the MCP server must call a downstream API, exchange the token for a new one scoped to that API (RFC 8693 token exchange) rather than forwarding the client's token46.
Token passthrough looks convenient and breaks three things at once: audience checks, rate limiting per client, and your audit trail. I treat it as a design-review blocker.
2. Proxies and the confused deputy
Many MCP servers are proxies in front of a third-party API. The guidance describes a confused deputy attack that appears when the proxy uses one static client ID with the third party, and that third party remembers consent per client ID rather than per user1. A malicious client can then ride on consent the user gave to someone else.
- Obtain the user's consent at the proxy for each dynamically registered client, before forwarding to the third-party authorisation flow.
- Validate redirect URIs exactly. No wildcards, no "starts with".
- Use state and PKCE properly, and expire authorisation codes quickly.
3. Least privilege, per tool
Scopes should describe what a tool can do, not which server it lives on. An MCP server that exposes "search tickets" and "close ticket" should not grant both with one scope.
| Tool type | Default policy | Extra control |
|---|---|---|
| Read, non-sensitive | Allowed for the user's own data | Rate limits, logging |
| Read, sensitive (PII, PHI, financials) | Allowed only if the user could see it directly | Field-level redaction, purpose logging |
| Write, reversible | Allowed with narrow scopes | Idempotency keys, undo path |
| Write, irreversible or external | Human approval required | Preview of the exact action, second factor |
The principle I hold to is simple: an agent should never be able to do something the human behind it couldn't do through the normal application. Permission-aware retrieval matters for the same reason, which I cover in the RAG production checklist.
4. Treat every input as untrusted
Prompt injection has no complete fix today, so design for containment5.
- Separate instructions from data. Tool results and retrieved documents are data. Mark them as such in the context and never let them change the agent's permissions.
- Constrain tool arguments. Validate against strict schemas server-side. An agent asking to email a thousand external addresses should fail validation, not reach your mail server.
- Watch tool descriptions. Descriptions from third-party MCP servers are text the model reads. Review and pin them, and alert when they change.
- Limit chaining. Cap how many tool calls an agent can make per task, and require approval when a read from an untrusted source is followed by a sensitive write.
5. Put a gateway in front
For enterprise use I put MCP servers behind a single AI gateway rather than letting agents connect to each server directly. One governed entry point gives you:
- Central authentication and token exchange.
- Per-user, per-tool authorisation policies written as code.
- PII redaction before data reaches a hosted model.
- Rate limits and cost controls per user and per agent.
- A complete, tamper-evident log of every tool call, its arguments and its result.
It is the same pattern I use for routing between local and hosted models, described in my notes on private LLMs.
6. Operate it like production
- Inventory. Know every MCP server in use, who owns it, which data it touches and which agents can call it.
- Pin versions. Treat third-party MCP servers like any other dependency: pinned, scanned, reviewed on upgrade.
- Session hygiene. Session IDs are not authentication. Bind sessions to the authenticated user and rotate them1.
- Red-team regularly. Keep a set of injection and misuse tests in the release pipeline, alongside quality evaluations.
- Plan the kill switch. You should be able to revoke a tool, a server or an agent's access in minutes.
The short version
If you only do five things: validate token audience, never pass tokens through, scope per tool, require human approval for irreversible actions, and log every tool call through a gateway. That covers most of the incidents I would expect to see.
Regulation is heading the same way. Logging, oversight and robustness are central to the EU AI Act's requirements for high-risk systems, which I discuss in the EU AI Act after the Digital Omnibus.
How I can help
I design and review agent platforms, from MCP server security to gateway architecture and evaluation. See my AI architecture work, or analyse your challenge and bring the result to a call. If you are an investor looking at an agent company, this checklist is part of my technical due diligence.
- 1Security Best PracticesModel Context Protocol documentation
- 2Authorization: Security ConsiderationsModel Context Protocol specification
- 3
- 4
- 5OWASP Top 10 for LLM ApplicationsOWASP GenAI Security Project
- 6Best practices for remote MCP bearer token authentication (Discussion #1247)GitHub, modelcontextprotocol