Where a gate sits in an MCP tool chain

This page is based on the MCP security best practices for protocol version 2026-07-28, which the MCP documentation lists as the current version at the time of writing.^[1][2]

What MCP adds to the picture

The Model Context Protocol (MCP) connects AI applications, acting as clients, to servers that expose tools and data. Protocol versions are named by date, marking the last time backwards-incompatible changes were made; the current version is 2026-07-28.^[2] The project publishes a security best-practices document for developers implementing MCP authorisation, for server operators and for security reviewers. It lists attacks specific to MCP implementations and the countermeasures expected for each.^[1]

Read with a runtime gate in mind, the useful thing about that list is that almost none of its mitigations ask the model to behave. They are checks on consent, tokens, URLs, processes and scopes, made by code around the model. That matches the design advice the UK NCSC and NIST give for prompt injection: constrain what the system can do with deterministic controls, rather than relying on the model to refuse.^[3][4]

Checkpoint 1: consent before a proxy acts for a user

An MCP proxy server that connects clients to a third-party API can become a confused deputy. The guidance describes the conditions: the proxy uses one static OAuth client ID with the third-party authorisation server, lets MCP clients register dynamically, and the third party sets a consent cookie after the first approval. An attacker registers a client with their own redirect address and sends the user a link. Because the consent cookie is already present, the third-party consent screen is skipped and the authorisation code is redirected to the attacker.^[1]

The required fix is a gate in the plainest sense. Proxies must keep a per-user registry of approved client IDs and check it before starting the third-party flow. Their own consent page must name the requesting client, show the scopes requested and the redirect address, and resist clickjacking. Redirect URIs must match the registered value exactly, with no patterns or wildcards. The OAuth state value must be random, single-use and short-lived (the guidance gives 10 minutes as an example), stored only after consent is approved and checked at the callback.^[1]

Checkpoint 2: tokens issued for this server only

“Token passthrough” is when an MCP server accepts a token from a client without checking that it was issued to that server, then forwards it to a downstream API. The MCP authorisation specification explicitly forbids it, and the rule in the guidance is short: MCP servers must not accept any tokens that were not explicitly issued for them.^[1]

The reasons read like a description of what a gate is for. Rate limits, request validation and monitoring that depend on a token’s audience are bypassed. The server can no longer tell its clients apart, and downstream logs show the wrong identity. A stolen token can turn the server into a proxy for data exfiltration.^[1] NIST’s proposed design tenets for agent identity make the same point from the identity side: access should be short-lived, specific to its audience and verified at each tool invocation or API call.^[4]

Checkpoint 3: outbound requests the client did not choose

During OAuth discovery, an MCP client fetches URLs that a malicious server can supply. That opens the door to server-side request forgery against internal network addresses, services on localhost or cloud metadata endpoints. The guidance recommends requiring HTTPS for OAuth URLs outside local development, blocking private, loopback and link-local address ranges, and applying the same checks to every redirect hop. For clients running on servers, it suggests an egress proxy that enforces network policy. It also warns against writing IP validation by hand, because encoding tricks defeat custom parsers, and notes that a domain can resolve to a safe address when checked and an internal one when used.^[1]

In gate terms, this is an allowlist for where the client may connect, enforced underneath the agent rather than by it.

Checkpoint 4: what runs on the user’s machine

Local MCP servers run on the same machine as the client and may have direct access to the user’s system. One of the attacks the guidance lists is a malicious startup command hidden in a client configuration. If a client offers one-click setup of a local server, it must show the exact command, without truncation, say plainly that it will execute code on the user’s system, and require explicit approval with the option to cancel. The guidance adds that clients should highlight dangerous patterns such as sudo or rm -rf, warn that servers run with the client’s privileges, and launch servers in a sandbox with minimal default access to files and the network.^[1]

The same caution applies to what a server sends back. Clients must accept only http and https authorisation URLs, with http limited to loopback addresses during development, must reject schemes such as javascript: and file:, and must not open URLs through a shell.^[1] A server’s output is treated as untrusted input, which is the stance this site takes towards model output as well.

Checkpoint 5: scopes that grow only when needed

Broad scopes granted up front widen the damage if a token leaks. The guidance recommends a minimal initial scope set covering low-risk discovery and read operations, with step-up elevation through targeted scope challenges when a privileged operation is first attempted, and logging of each elevation event. Its list of common mistakes includes wildcard or “full-access” scopes, bundling unrelated privileges to avoid future prompts, and treating the scopes a token claims as sufficient without server-side authorisation logic.^[1]

The guidance is candid that the default leans the other way. When a server’s first challenge names no scope, clients are directed to request every scope the server lists, leaving the authorisation server and the user to narrow them at consent.^[1] So much of the least-privilege burden sits with the server’s challenges. OWASP’s Excessive Agency entry gives the general version of the rule: give an agent the narrowest permissions it needs, and enforce authorisation in downstream systems rather than leaving the model to decide.^[5]

Each server is a supplier

Every MCP server an agent connects to is third-party code or a third-party service. OWASP’s LLM03:2025 Supply Chain entry is written mainly about packages, pre-trained models and fine-tuning adapters, and does not mention MCP. Its mitigations still transfer: vet suppliers and review their security posture regularly, keep an up-to-date and signed inventory of components with a software bill of materials, use code signing for externally supplied code, and patch or replace outdated components.^[6] Applying that list to MCP servers is this page’s reading, not OWASP’s.

What the guidance does not cover

The MCP best-practices document is about authorisation, transport and process boundaries. It does not discuss instructions hidden in tool descriptions or tool results.^[1] That content reaches the model as data, and the problem described in why prompt injection needs a gate outside the model applies: assume some injected instructions will get through, and limit what a misled agent can do.^[3]

A short checklist

1. Proxies: per-client consent, exact redirect URI matching and single-use, short-lived state.^[1]
2. Servers: reject any token not issued for this server, and never pass client tokens downstream.^[1]
3. Clients: HTTPS only, block private and link-local ranges, check every redirect, and use an egress proxy where possible.^[1]
4. Local servers: show the full command, require approval and run sandboxed with minimal privileges.^[1]
5. Scopes: start minimal, elevate per operation, log each elevation, and authorise on the server.^[1][5]
6. Suppliers: inventory, signing and patching for every server in the chain.^[6]

For the wider picture, see what a model bouncer is.