MCP Security Architecture: Authentication, Authorization, and Supply Chain Controls for the Protocol That Connects AI to Everything

The Model Context Protocol was designed to be the universal connector for AI. One protocol, one integration pattern, one way for any AI model to interact with any external tool, database, or service. Anthropic called it the "USB-C for AI." The analogy was clever marketing. But USB-C shipped with defined electrical safety standards on day one. MCP shipped without mandatory authentication.

Between November 2024 and June 2025, the protocol accumulated 8 million SDK downloads, over 5,800 deployed servers, and integrations at Bloomberg, Amazon, and hundreds of Fortune 500 companies. All before a single mandatory authentication requirement existed in the specification.

The June 2025 specification update introduced OAuth 2.1 as a requirement. The November 2025 anniversary update added stricter local server security, default authorization scopes, and machine-to-machine authentication flows. By December 2025, Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation, signaling institutional commitment to the protocol's future.

The specification is now on a credible security path. The ecosystem it governs is not.

There are two populations of MCP servers in the world. Servers built after June 2025, which must implement OAuth 2.1 to be spec-compliant. And servers built before June 2025, which have no obligation to upgrade and which form the majority of deployed infrastructure. This guide covers both: how to implement the specification correctly for new servers, and how to audit, remediate, or decommission the servers that predate it.

MCP Protocol Security Reference Architecture

A compliant MCP deployment, as of the June 2025 specification, consists of four components with distinct security responsibilities.

The MCP Client is the AI application that connects to MCP servers. The client authenticates users, manages sessions, and initiates tool calls. The client is responsible for enforcing tool-call allowlists, validating tool definitions, and presenting tool approval interfaces to users.

The MCP Server is the gateway to external systems. It exposes tools, data sources, and capabilities to the client via JSON-RPC 2.0. Post-June 2025, the server must function as an OAuth 2.1 Resource Server: serving Protected Resource Metadata, validating access tokens, and returning proper WWW-Authenticate headers when rejecting unauthenticated requests.

The Authorization Server is the external identity provider that issues and manages tokens. The June 2025 update separated this concern cleanly from the MCP server. Earlier versions blurred the line between MCP servers as authorization servers and MCP servers as resource servers, forcing server developers to implement complex token management logic that most got wrong.

The External Systems are the databases, APIs, SaaS platforms, and services that the MCP server connects to. Each requires its own credentials, which the MCP server stores and manages. This credential concentration is a primary attack surface.

The Trust Boundaries

The architecture has three trust boundaries that must be defended independently.

Boundary 1: Client to Server. The client must verify the server's identity (TLS). The server must verify the client's authorization (OAuth 2.1 token validation). The token must be scoped to the specific server via Resource Indicators (RFC 8707).

Boundary 2: Server to External System. The server holds credentials for external systems. These credentials must be stored securely (secrets management, not environment variables or config files). Access must be scoped to the minimum permissions needed. Credential rotation must be automated.

Boundary 3: Tool Definition to Execution. The server defines tools and the client executes them. The tool definitions themselves are an attack surface: embedded instructions in tool descriptions can alter agent behavior. The client must validate tool definitions against an approved manifest and detect unauthorized changes.

What OAuth 2.1 Covers and What It Does Not

What the Specification Requires

After the June 2025 update, MCP servers classified as remote servers (network-accessible) must implement the following:

Protected Resource Metadata. Every MCP server must serve a .well-known/oauth-protected-resource document that describes its authorization requirements. Clients use this to discover which authorization server to contact and what scopes to request.

Token Validation. The server must validate access tokens against the designated authorization server. Tokens must be checked for expiration, scope, audience, and issuer. Invalid tokens must produce a 401 response with a proper WWW-Authenticate header.

Resource Indicators (RFC 8707). When a client requests a token, it must specify which MCP server the token is intended for using the resource parameter. The authorization server scopes the token to that specific server. This prevents a compromised server from reusing a token it received to access other protected resources on the user's behalf, the confused deputy attack.

PKCE (Proof Key for Code Exchange). Required for all client types, including confidential clients. PKCE prevents authorization code interception attacks during the OAuth flow.

What the Specification Does Not Cover

Tool redefinition attacks. MCP servers can dynamically change the tools they expose after a client has connected and approved an initial set of tools. The specification added security guidance but no mandatory mechanism to prevent or detect tool redefinition. A server that passes your security audit on Monday can change its behavior on Tuesday.

Supply chain verification. The specification defines how servers authenticate to clients but not how clients verify the provenance or integrity of a server's code. The MCP Registry is for public server discovery, not enterprise security vetting.

Monitoring and observability. The specification leaves monitoring entirely to implementors. There is no standard format for MCP audit logs, no required telemetry, and no specification-level support for security monitoring.

Dynamic Client Registration (DCR). DCR, which allows MCP clients to automatically register with new authorization servers, is recommended but not required. Some authorization servers have documented compliance challenges with DCR, requiring workarounds that deviate from the specification.

Authorization Patterns for MCP Tool Calls

Pattern 1: User Identity Propagation

The preferred pattern for any MCP tool that acts on behalf of a user. The client obtains an access token scoped to the user's identity and permissions. When the MCP server calls an external system, it exchanges the user's token for a downstream token using OAuth 2.0's On-Behalf-Of (OBO) flow, preserving the user's identity and authorization scope at every hop.

This pattern ensures that the MCP server never operates with broader permissions than the user it serves. Audit logs trace back to the specific human who initiated the action. Compliance frameworks (SOX, GDPR, HIPAA) require this level of traceability for actions that modify regulated data.

Pattern 2: Scoped Service Credentials

For MCP tools that perform system-level operations not tied to a specific user (scheduled maintenance, batch processing, system health checks), scoped service credentials are acceptable. The key constraint is scope: the service credential must have the minimum permissions needed for the specific tool's function, and nothing more.

Pattern 3: Just-in-Time Authorization

For high-sensitivity tool calls (financial transactions, data deletion, privilege escalation), implement just-in-time authorization that requires explicit user confirmation before execution. The MCP client presents the tool call details to the user, the user approves, and only then does the client issue the authorized request to the server. This prevents a compromised or manipulated agent from executing consequential actions without human awareness.

Manifest Pinning Implementation Guide

Manifest pinning is the primary defense against tool redefinition attacks. The concept is straightforward: when a client first connects to an MCP server, it captures the complete set of tool definitions (the manifest). On subsequent connections, it compares the current manifest against the pinned version and alerts on any changes.

Implementation Steps

Step 1: Capture the initial manifest. On first connection to an approved MCP server, serialize the complete tool definitions including names, descriptions, parameter schemas, and annotations. Store this as the pinned manifest with a timestamp and the server's identity (TLS certificate fingerprint or OAuth client ID).

Step 2: Hash and sign. Generate a cryptographic hash of the pinned manifest. If your organization uses a PKI, sign the hash with a key controlled by the security team. This prevents tampering with the pinned manifest itself.

Step 3: Compare on every connection. Before executing any tool calls, the client retrieves the server's current tool definitions and compares them against the pinned manifest. Any difference, whether in tool names, descriptions, parameter schemas, or annotations, triggers an alert and blocks tool execution until the change is reviewed and approved.

Step 4: Implement a review workflow. When a manifest change is detected, route it to the security team for review. Legitimate changes (new tools, updated descriptions, schema refinements) should be approved and the pinned manifest updated. Unauthorized changes (modified descriptions with embedded instructions, altered parameter schemas, removed tools) should trigger a security investigation.

What Manifest Pinning Does Not Catch

Manifest pinning protects against tool redefinition but not against tool behavior changes. A tool whose definition remains identical but whose server-side implementation changes (returning different data, executing different code) will pass manifest validation. Defense against implementation changes requires runtime monitoring of tool call inputs and outputs, which is a separate control.

MCP Server Allowlisting Methodology

Discovery: Finding Your MCP Servers

MCP adoption was developer-driven, not centrally managed. Developers adopted MCP servers the way they adopt any promising open-source tool: quickly and often without informing security teams. Your first challenge is finding them.

Scan for MCP processes. Search for running processes associated with known MCP server frameworks (Python MCP SDK, TypeScript MCP SDK). Check container registries for MCP-related images. Scan CI/CD pipelines for MCP deployment configurations.

Search code repositories. Grep for MCP-related dependencies in package manifests (package.json, requirements.txt). Search for MCP configuration files (.mcp.json, mcp-config files). Check infrastructure-as-code templates for MCP server provisioning.

Monitor network traffic. MCP servers communicate over JSON-RPC 2.0. Monitor for JSON-RPC traffic patterns on non-standard ports. Check network logs for connections to known MCP-related endpoints.

Check developer machines. MCP servers can run locally on developer laptops, connected to cloud-hosted AI applications. Survey development teams about MCP tool usage. Check for MCP client configurations in AI coding assistants (Claude Code, Cursor, Windsurf).

Assessment: Evaluating Each Server

For each discovered MCP server, evaluate against the June 2025 specification:

Any server that fails these checks must be upgraded, replaced, or decommissioned on a defined timeline.

Enforcement: Blocking Unapproved Servers

Implement MCP server allowlists at the network and application level. Only approved, audited servers should be accessible from production environments. Block connections to unapproved servers using the same mechanisms you use to block connections to unapproved APIs: network policy, proxy rules, or application-level allowlists in MCP client configurations.

Supply Chain Audit Checklist

The February 2026 CVE wave (seven CVEs in one month, all from the same root cause category) demonstrated that MCP server supply chain risk is not theoretical. Analysis of 554 network-exposed MCP servers found that 37% had no authentication. Among 2,614 MCP implementations studied, 82% used file system operations prone to path traversal and 67% used APIs susceptible to code injection.

For Every MCP Server in Your Environment

1. Provenance. Where did this server's code originate? Is it maintained by a reputable organization with a security disclosure process? When was it last updated?

2. Dependency audit. What packages does this server depend on? Are any dependencies known-vulnerable? The mcp-remote npm package (used to add OAuth support) contained CVE-2025-6514. Run SCA tools against all MCP server dependencies.

3. Code review for unsafe patterns. Search for eval(), exec(), child_process.exec, subprocess.run(shell=True), and equivalent dynamic execution patterns. These are the root cause of the February 2026 CVE cluster. Any MCP server that passes user-supplied input to these functions without sanitization is vulnerable to command injection.

4. Network exposure. Is this server bound to 0.0.0.0 (all interfaces) or to localhost only? Hundreds of MCP servers were found configured by default to bind to all interfaces, exposing command execution paths to the network. The NeighborJack disclosure in June 2025 documented this at scale.

5. Authentication enforcement. Does the server require authentication for all endpoints? Some servers enforce authentication for tool calls but not for metadata endpoints, creating information disclosure vectors.

6. Configuration injection. Can repository-controlled configuration files override security settings? The Claude Code vulnerabilities (CVE-2025-59536, CVE-2026-21852) demonstrated that .claude/settings.json and .mcp.json files could launch MCP servers before user approval, because configuration files were treated as metadata rather than potential execution vectors.

Rug Pull Defense Patterns

The "rug pull" attack exploits MCP's dynamic tool redefinition capability. A server you approved exposes Tool A on Monday. By Tuesday, Tool A's definition has changed server-side. The tool name is the same. The description now contains hidden instructions that alter agent behavior. Or the tool's implementation now exfiltrates data instead of performing its stated function.

Defense 1: Manifest Pinning (Covered Above)

Detects changes to tool definitions. Does not detect changes to tool behavior.

Defense 2: Tool Call Input/Output Monitoring

Log every tool call with full input parameters and output responses. Establish behavioral baselines: what inputs does this tool typically receive, and what outputs does it typically produce? Alert on anomalies. A database query tool that suddenly returns response payloads ten times larger than baseline, or a file system tool that starts accessing paths outside its expected directory, warrants immediate investigation.

Defense 3: Canary Tool Calls

Periodically issue known-good test queries to MCP tools and verify that the responses match expected outputs. This is the tool-call equivalent of a health check, but it validates behavioral consistency rather than just availability.

Defense 4: Tool Description Sanitization

Before presenting tool descriptions to the LLM, strip or neutralize content that could function as prompt injection. Tool descriptions should describe what the tool does, not instruct the model how to behave. Scan descriptions for imperative language directed at the model, encoded content, and anomalous formatting.

CVE Reference Table with Remediation

The Remediation Timeline

Immediate (This Week)

Inventory every MCP integration. Check developer machines, container registries, CI/CD pipelines, and cloud deployments. For each server, determine when it was deployed and whether it predates the June 2025 specification.

Short-Term (30 Days)

Assess every discovered server against the June 2025 specification checklist. Decommission or isolate servers that fail critical requirements (no authentication, no token validation, known CVEs). Implement network-level allowlisting to block connections to unapproved servers.

Medium-Term (90 Days)

Deploy manifest pinning for all approved MCP servers. Implement tool call monitoring and behavioral baselining. Integrate MCP servers into your standard vulnerability management process, including dependency scanning and regular patching.

Ongoing

Maintain your MCP server inventory as a living document. Establish a review process for new MCP server requests. Monitor the MCP CVE landscape (it is accelerating, not stabilizing). Participate in or monitor the Agentic AI Foundation's security working groups for specification updates.

The Protocol Matured. The Ecosystem Hasn't.

MCP's specification is now technically sound. The OAuth 2.1 mandate, Resource Indicators, PKCE requirements, and separation of resource server and authorization server concerns represent competent protocol security engineering.

The problem is the deployed base. Thousands of servers built during the authentication-optional period are running in production. Developer behavior follows predictable patterns: they search GitHub, fork a popular implementation, modify it, and deploy it. They rarely check whether the implementation conforms to the current specification. The server works. That is the test.

This guide exists because the gap between the specification and the ecosystem is where breaches will live. The specification tells you what "correct" looks like. This guide tells you how to find and fix everything that isn't.

Nik Kale is a Principal Engineer and Product Architect with 17+ years of experience building AI-powered enterprise systems. He is a member of the Coalition for Secure AI (CoSAI), contributes to IETF AGNTCY working groups, and serves on the ACM AISec and CCS Program Committee. The views expressed here are his own.