Treat every MCP server as a software-supply-chain and identity boundary

Source facts: MCP standardizes connection mechanics, not supplier trust

The Model Context Protocol 2026-07-28 authorization specification defines an OAuth-based authorization flow for HTTP transports. It requires protected MCP servers that implement this flow to validate access tokens intended for their own resource, prohibits accepting or transiting tokens meant for other resources, supports scope challenges and step-up authorization, and identifies security concerns including token theft, audience confusion, redirect abuse, and confused-deputy behavior.

The specification also states that authorization is optional for MCP implementations. HTTP implementations should conform when authorization is supported, while stdio deployments retrieve credentials from their environment instead of using the HTTP flow. The server-tools specification places responsibilities on servers to validate input, enforce access controls, rate limit invocations, and sanitize output. Clients are advised to treat tool annotations as untrusted unless the server is trusted, show inputs for sensitive operations, validate results, use timeouts, and log tool use.

Those protocol rules do not certify a publisher, inspect source code, attest a package, prove a tool description is honest, or determine whether a requested operation is appropriate for a business process. NIST SP 800-161 Rev. 1 treats acquired products and services as supply-chain risks that require identification, assessment, and mitigation throughout their lifecycle. An MCP server therefore belongs in both the software-supplier register and the identity and access design.

DSE recommendation: approve the server, the tool catalog, and every authority path

Do not approve “MCP” in the abstract. Approve a named server, publisher, version, transport, deployment, tool set, data path, and owner for a defined use.

1. Inventory the dependency. Record publisher, repository or distribution source, license, maintainer, version, package hashes or signatures where available, hosting party, support status, vulnerability and update channels, transport, endpoints, data classes, tools, downstream services, and business owner.
2. Review tool definitions as influential code. Capture names, descriptions, schemas, annotations, parameters, output, side effects, and external destinations. Look for descriptions that instruct the agent beyond the tool’s purpose, broad catch-all operations, hidden network access, arbitrary code or query execution, and changes that expand authority.
3. Design authorization by resource. For remote HTTP servers, follow the current MCP authorization specification, validate issuer and audience, request the minimum scopes needed for the operation, protect refresh tokens, set retry limits, and use a separate downstream token rather than passing the client’s token through. For local servers, restrict the process identity, environment credentials, file access, and inherited network reach.
4. Constrain execution. Allowlist servers, tools, parameters, target systems, file paths, and outbound destinations. Separate read from write tools and development from production. Put consequential actions behind deterministic approval and transaction limits outside the model.
5. Govern change. Pin versions where operationally appropriate, monitor registry and repository changes, diff tool definitions, reassess new scopes and destinations, test updates in isolation, and require explicit approval before a new or materially changed tool reaches production.
6. Observe and revoke. Log discovery, authorization, scope increases, calls, results, denials, timeouts, server versions, and downstream effects without exposing secrets. Rehearse disabling the server, removing client configuration, revoking tokens and credentials, blocking its network path, preserving evidence, and restoring the workflow without it.

Factual boundary: MCP authorization requirements depend on transport and implementation. Conformance to the protocol is not proof that a server, tool description, returned value, or publisher is safe. The protocol evolves; pin the article to the cited 2026-07-28 specification and recheck the current version before implementing controls.

Track unowned servers, unpinned production dependencies, changed tool definitions, excessive scopes, unapproved destinations, failed token validation, and overdue removal tests. The safe operating question is not “Does this client support MCP?” It is “Which exact server and tools are trusted to do what, using whose identity, against which systems, and how quickly can that trust be removed?”

Official references

• Model Context Protocol, Authorization, specification version 2026-07-28.
• Model Context Protocol, Tools, specification version 2026-07-28.
• NIST, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, SP 800-161 Rev. 1.