AI Agent Identity and Authorization: What NIST's New Initiative Means for Your MCP Stack

When you authenticate to a service via an MCP server, who exactly is making that request?

Most implementations today have an honest but uncomfortable answer: a bearer token that identifies the user, operated by an agent whose identity is nowhere in the request. The user is verified. The agent is invisible.

NIST formalised this problem in February 2026 with its AI Agent Identity and Authorization Initiative. Microsoft landed the same concept in their Entra Agent ID documentation shortly after. The MCP specification has updated its security best practices to make the gap explicit: bearer tokens alone do not identify the MCP client making the call.

This is not a theoretical concern. It is an operational gap that production agent teams are already hitting.

The three-layer problem

User identity, agent identity, and authorization are separate things that most current stacks treat as one thing.

User identity is the token in the request. It says who the human operator is. It is what OAuth was designed to establish.

Agent identity is the answer to: which agent, running which skills, with which version of those skills, is acting on behalf of that user right now? Today, this is typically blank. The service sees a valid user token and proceeds.

Authorization is what the agent is allowed to do — not just what the user is allowed to do. A user might have write access to a secrets vault. That does not mean every agent acting as that user should inherit write access to that vault.

When all three collapse into a single bearer token, you lose the ability to audit, constrain, or quarantine individual agents. You can revoke the user, but you cannot revoke one misbehaving agent without taking down the user's entire session.

What the standards are saying

NIST's initiative targets this gap directly. Their framing: AI agents acting as proxies for users need verifiable identities of their own so that access controls can be applied at the agent level, not just at the user level.

Microsoft's Entra Agent ID goes further operationally: registered agent identities, scoped permissions, and the ability to issue or revoke agent credentials independently of the human account. It is the same model as service accounts in traditional infrastructure, applied to agentic runtime.

The MCP specification adds a protocol-level note: because HTTP-based MCP uses standard web auth, the server sees only what the transport layer carries. If the implementation relies on user tokens without an additional client registration layer, agent identity is missing from every request.

What this means if you run an MCP stack today

Running Claude Code or a similar agent against MCP servers right now almost certainly means your MCP servers are seeing user tokens with no agent-level attribution.

That creates three concrete risks:

Audit gaps. If an agent takes a destructive action, your audit trail shows the user's token, not which skill or agent version triggered it. Tracing the root cause requires correlating logs across multiple systems manually.

Scope creep. Without per-agent authorization, agents inherit the full permission surface of their user token. Skills installed by one agent can make requests that no human explicitly authorised at the agent level.

Undetectable substitution. A compromised or tampered skill can act under the user's identity with no signal to the downstream service that something changed. Container isolation protects the host from the agent process. It does not protect downstream services from an agent whose permissions were never scoped.

What you can do before the tooling catches up

Full agent identity and authorization infrastructure is coming — NIST's initiative and Microsoft's Entra work are early leading indicators, not mature tooling. In the meantime, a few defensive patterns help:

1. Pre-install skill review. Before adding any skill to your agent stack, verify what tool calls it makes and what scopes it requests. SkillShield's scanner surfaces this before the skill runs.

2. Minimum-scope tokens. Issue MCP server tokens with the smallest scope that covers legitimate use. Do not use admin or write-all tokens for agent contexts unless the task explicitly requires them.

3. Skill version pinning. If a skill auto-updates, its tool descriptions and API surface can change without notice. Pinning versions gives you a stable audit baseline and makes scope drift detectable.

4. Explicit authorization logging. Log which skills are active per session. When NIST-compatible agent identity tooling ships, you will want a local log to reconcile against.

The shape of what's coming

The MCP protocol discussion is already moving toward signed client registration and capability declarations. GitHub issues on the MCP spec show builder demand for verifiable client identity at the protocol level. NIST's initiative will likely produce a reference architecture that vendors can implement.

The window to get ahead of this — to publish practical guidance before the standards crowd out the search results — is now. The terminology is stabilising. The SERP is not yet owned.

SkillShield's position in that future: the tool that gives you agent-level skill attribution before the platform-level infrastructure exists. Pre-install verification is the best currently available substitute for per-agent authorization in production stacks.

Sources

• https://www.nist.gov/news-events/news/2026/02/nist-launches-ai-agent-identity-and-authorization-initiative
• https://www.nccoe.nist.gov/ai-agent-identity-and-authorization
• https://learn.microsoft.com/en-us/entra/agent-id/identity-platform/what-is-agent-id
• https://modelcontextprotocol.io/specification/draft/basic/security_best_practices
• https://github.com/modelcontextprotocol/modelcontextprotocol/issues/544 (builder demand for client identity)
• https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/1289 (signatures + client registration)