NSA’s MCP security design considerations draw attention to the trust placed in servers, clients, credentials and tool execution. A successful sign-in is one piece of that boundary; an authorized consequence is another.
01 / Read the source
What the primary material says
The official MCP authorization specification requires the token to be intended for the protected resource and describes discovery for the HTTP flow. NSA’s guidance considers how MCP’s connection to external systems creates security consequences. Together they support a review that begins with who holds credentials, what a server can do downstream, and which principal initiated a call.
NSA’s guidance is a design consideration document. Its recommendations should be applied to the actual deployment and threat model; a local server with one trusted operator is different from a shared remote service spanning tenants. The MCP specification supplies protocol rules, while business-specific values such as payment amount or customer identity must come from the enterprise system.
02 / Architectural consequence
Where the trust boundary changes
A shared MCP server may be authorized to call a database with a powerful service credential. Even if each client authenticates correctly, the server still needs to decide which tool, query and tenant that client’s task allows. A gateway can mediate calls that traverse it, but direct server connections and downstream APIs need their own enforcement plan.
Follow the credential into the downstream system
The server may hold a credential powerful enough to read or mutate resources in another system. A client’s authentication to the server tells the server which caller connected, but the downstream API may see only that shared server identity. That is the point where authority can be lost. Preserve caller and task context in a policy decision, constrain the server credential and verify that the protected operation is checked before the effect. If a server can call another API outside the gateway path, the gateway’s complete log is not a complete execution record.
03 / ProofGrid analysis
Authority beyond the credential
ProofGrid frames that missing link as authority: an originating grant with purpose and scope that can be checked at the effect boundary. The practical question is not whether MCP is secure or insecure in the abstract; it is which part of the full chain each control actually covers.
04 / A testable next step
What a security architect can do
Document token audience validation, server credential scope, tool permissions and direct paths. Attempt a cross-tenant request and an unauthorized write in a test environment, then compare protocol logs with the downstream result.
Who owns the downstream credential, and can it be scoped per client or task? Does a server log retain the initiating principal? Can an attacker change tool arguments without changing the OAuth scope? Does an alternate path reach the protected API? The answers show where transport authentication stops being sufficient.
Primary sources
Read the documents
Durable references