NIST Evaluates MCP for AI Agent Identity Governance

NIST has published a draft concept paper that explicitly names the Model Context Protocol as one of five standards under evaluation for agentic AI identity governance. MCP now sits alongside OAuth 2.0/2.1 with OIDC, SPIFFE/SPIRE, SCIM, and NGAC in a framework that will likely shape federal procurement, enterprise adoption, and regulatory compliance for years.

This is a significant moment for MCP. A protocol that started as Anthropic’s tool integration standard is now being evaluated by the United States’ primary standards body for cybersecurity. The implications extend far beyond technical specification.

The Five Standards Under Evaluation

NIST’s concept paper evaluates five standards for their applicability to agentic AI identity:

MCP (Model Context Protocol) is assessed primarily for its role in tool discovery and invocation — the interface layer between AI agents and external capabilities. NIST recognizes that MCP’s adoption (97 million monthly SDK downloads) makes it a de facto standard for agent-tool communication, but notes significant gaps in its authentication and authorization model.

OAuth 2.0/2.1 with OIDC is the established standard for delegated authorization. NIST evaluates it as the most mature candidate for handling user-to-agent credential delegation, but notes that OAuth was designed for human-initiated flows and requires adaptation for autonomous agent scenarios.

SPIFFE/SPIRE (Secure Production Identity Framework for Everyone) provides workload identity — cryptographic identity for services and processes rather than humans. NIST sees SPIFFE as potentially relevant for agent-to-agent authentication, where each agent needs a verifiable identity that is not tied to a human user.

SCIM (System for Cross-domain Identity Management) handles identity provisioning and lifecycle management. In the agentic context, NIST considers SCIM for managing the creation, modification, and deprovisioning of agent identities across organizational boundaries.

NGAC (Next Generation Access Control) is a flexible access control framework that can express complex authorization policies. NIST evaluates NGAC as a candidate for defining what agents are allowed to do — the policy layer that sits above authentication.

No single standard covers the full problem space. NIST’s framework implicitly suggests that a composite approach will be necessary, with different standards handling different layers of the identity stack.

Five Unsolved Problems

NIST’s paper identifies five governance problems that remain unsolved for agentic AI:

Agent Identification

How do you uniquely identify an AI agent? This is not the same as identifying a user or a service. An agent may be a transient process spawned by another agent, running on shared infrastructure, with no persistent identity. It may be one of thousands of identical instances. Current identity frameworks assume long-lived entities with stable identifiers — a poor fit for the ephemeral, composable nature of AI agents.

MCP does not address agent identification at the protocol level. An MCP server sees incoming tool calls but cannot reliably determine which agent is making them, whether it has seen this agent before, or whether the agent is who it claims to be.

Key Management

Agent authentication requires cryptographic credentials — tokens, certificates, or keys. Managing these credentials at agent scale is an unsolved logistics problem. Agents may spin up and shut down in seconds. They may delegate tasks to sub-agents that need their own credentials. The credential lifecycle (issuance, rotation, revocation) must operate at machine speed, not human administrative speed.

The CVE-2025-6514 vulnerability in mcp-remote demonstrated what happens when credential handling is implemented poorly — a command injection in the OAuth flow that affected 558,000+ installations. Secure key management is not optional; it is the foundation that everything else rests on.

Zero-Trust Least-Privilege

Every agent should have exactly the permissions it needs for its current task and nothing more. This is the zero-trust principle applied to agentic AI, and it is extraordinarily difficult in practice.

An agent connected to 10 MCP servers has the union of all permissions granted across those servers. MCP does not support per-invocation permission scoping — once an agent has access to a tool, it has access to that tool for all purposes. A coding agent that needs to read a file for context also has permission to read every file the tool allows, regardless of whether the current task requires it.

Delegation Chain Tracking

When Agent A delegates a task to Agent B, and Agent B uses credentials originally granted to Agent A, who is responsible for the actions taken? The delegation chain — the sequence of agents that handled a request from origin to execution — must be tracked and auditable. But MCP has no concept of delegation chains. Each tool call is independent, with no metadata linking it to the request that prompted it.

This is particularly problematic for multi-agent systems where a supervisor agent distributes work to specialized sub-agents. The sub-agents act with the supervisor’s authority but may make autonomous decisions about which tools to invoke and how.

Audit Trail Integrity

Every action taken by every agent must be logged in a tamper-evident record that can survive agent termination, infrastructure failures, and adversarial attempts to cover tracks. Current MCP implementations produce logs, but those logs are typically stored on the same infrastructure the agent runs on. An agent that has been compromised can modify its own logs.

NIST’s paper suggests that agent audit trails should be cryptographically signed and stored in append-only systems separate from the agent’s execution environment. None of the five evaluated standards currently provide this capability out of the box.

The MCP Dev Summit Connection

The timing of NIST’s paper is not coincidental. The MCP Dev Summit, organized by the Linux Foundation, is scheduled for April 2-3 in New York City. NIST representatives are scheduled to present at the summit, directly engaging with the MCP developer community on governance requirements.

This is the first time a federal standards body has engaged directly with the MCP ecosystem at a developer event. Previous NIST involvement in protocol standardization — with TLS, OAuth, and FIDO — has historically preceded formal standardization processes. The MCP Dev Summit presentations could signal whether NIST intends to recommend MCP as part of a formal agentic identity standard or identify gaps that must be addressed first.

The Linux Foundation’s involvement adds institutional weight. The Foundation’s track record with open standards (Kubernetes, Linux, OpenSSL) provides a governance model for MCP’s evolution from a single-company project to a community-governed standard. The summit’s agenda includes working groups on authentication, tool safety, and governance — all areas where NIST has identified gaps.

OAuth 2.1 Integration and Capability Negotiation

The MCP specification’s 2025 revision made two changes relevant to NIST’s evaluation:

OAuth 2.1 integration standardized how MCP servers authenticate clients using OAuth flows. This replaced the ad-hoc token handling that characterized early MCP implementations. OAuth 2.1’s requirements for PKCE (Proof Key for Code Exchange) on all grant types and the deprecation of implicit flows align with NIST’s security recommendations.

However, the integration is at the transport level — MCP defines how to pass OAuth tokens to servers, but not how to scope those tokens per tool, per invocation, or per delegation chain. The confused deputy problem remains unaddressed by the OAuth integration alone.

Capability negotiation allows MCP clients and servers to declare their capabilities during the connection handshake. A server can advertise which authentication mechanisms it supports, and a client can select the appropriate one. This is a step toward the kind of dynamic trust establishment that NIST’s framework envisions, but it currently covers feature negotiation rather than security policy negotiation.

What Institutional Backing Means for Enterprise Adoption

NIST’s evaluation of MCP has immediate practical consequences for enterprise adoption. Federal agencies and their contractors are required to follow NIST guidelines for cybersecurity. If NIST includes MCP in its recommended standards for agentic AI, it becomes a procurement requirement for a significant portion of the enterprise market.

More broadly, NIST endorsement provides the institutional validation that risk-averse enterprises need before adopting new protocols. Many organizations have delayed MCP adoption precisely because it lacked the kind of third-party security evaluation that NIST provides. A positive NIST assessment removes that blocker.

Conversely, if NIST identifies fundamental gaps in MCP’s security model — which the current draft paper suggests it will — those gaps become formal requirements for the MCP specification to address. This creates healthy pressure on the specification process to prioritize security over feature development.

The Gap Between Specification and Implementation

NIST’s evaluation highlights a persistent challenge in the MCP ecosystem: the gap between what the specification defines and what implementations actually do.

The MCP specification has been tightening its security requirements with each revision. OAuth 2.1 is now specified. Input validation is documented. Transport security requirements are clear. But specification compliance is not enforced. There is no MCP conformance testing suite, no certification process, and no mechanism to verify that an MCP server implements the security requirements correctly.

This gap is common in early-stage protocol ecosystems. HTTP went through a similar phase, as did OAuth itself. The difference is that MCP servers are being deployed in production with real-user credentials right now, at a scale where specification non-compliance has immediate security consequences.

NIST’s involvement could accelerate the creation of conformance testing and certification. The NIST Cybersecurity Framework’s concept of “profiles” — specific sets of requirements for specific use cases — could provide a model for MCP security certification levels.

What You Should Do Now

NIST’s evaluation does not change what you should build today, but it changes how you should plan for tomorrow:

1. Track the NIST process. The draft concept paper will go through public comment and revision. The final framework will establish the baseline security requirements for agentic AI in regulated industries. If you are building MCP infrastructure, align with NIST’s requirements as they crystallize.

2. Attend or follow the MCP Dev Summit. The April 2-3 event in NYC will be where NIST’s requirements meet the MCP developer community. The decisions made there will shape the protocol’s governance trajectory.

3. Implement OAuth 2.1 now. This is the one area where MCP’s specification, NIST’s evaluation, and industry practice are converging. If your MCP servers are still using ad-hoc token handling, migrating to OAuth 2.1 is the lowest-risk investment you can make.

4. Design for auditability. NIST’s emphasis on audit trail integrity signals that logging requirements for agentic systems will become more stringent. Instrument your MCP deployments with comprehensive logging now, even if no regulation currently requires it.

5. Prepare for delegation chain requirements. This is the area where NIST is most likely to drive new MCP specification requirements. If you operate multi-agent systems, start tracking the causal chain from user request to tool invocation, even if MCP does not yet provide protocol-level support for it.

MCP’s inclusion in NIST’s evaluation framework is a sign of the protocol’s growing importance. But importance brings scrutiny, and the MCP ecosystem has significant work ahead to meet the governance standards that institutional adoption demands.