NIST Just Defined Identity for AI Agents. Here's What Changes.
Run agents? ACP lets you see, control, and price every tool call they make — free on-device install for Claude Code, Cursor, Codex, and OpenClaw, nothing leaves your machine:
curl -sf https://agenticcontrolplane.com/install.sh | bash -s -- --localGetting started → · or use the free cloud console → · free for individuals
Eighty percent of Fortune 500 companies are deploying AI agents. Only 14.4% have full security approval for those deployments.
On February 17, 2026, NIST’s Center for AI Standards and Innovation launched the AI Agent Standards Initiative. The NCCoE published a concept paper titled “Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization.” The public comment period closes in early April 2026. This is the first time the U.S. federal government has intervened at the national level to set interoperability and security standards specifically for autonomous AI agents.
The message: AI agents should be treated as identifiable entities, not anonymous automation running under shared credentials. If you’re building agent infrastructure, read the concept paper.
What NIST actually published
The initiative rests on three pillars: industry-led standards, community-led open source protocols (with an explicit nod to MCP), and security and identity research. The RFI — published January 8, 2026 in the Federal Register — received 932 comments before closing on March 9, 2026.
NIST organized the initiative around six thematic areas:
- Agent identity and authentication — treating agents as first-class identities, not service accounts
- Stricter authorization — deny-by-default, per-action scope evaluation
- Post-deployment monitoring — continuous trust validation after the agent ships
- Prompt injection as an architecture problem — not a model problem or an input validation problem
- Interoperability — cross-platform identity propagation that works regardless of model provider or framework
- Human-agent interactions — explicit session boundaries, delegated authority, and revocation
The protocols referenced are telling: OAuth, OpenID Connect, SCIM, SPIRE, NGAC. These are identity infrastructure protocols, not AI-specific inventions. NIST is putting agent identity in the same architectural category as human identity, enforced by the same infrastructure.
What the RFI respondents said
The 932 RFI comments weren’t abstract policy opinions. The OpenID Foundation’s response cuts to the core: “The most urgent AI agent security risks are not technical failures, but failures of trust.”
They advocate for a “trust fabric” that verifies credentials automatically — because without automated verification, systems default to “allow everything.” That describes what’s deployed today. Shared API keys. Service accounts with admin access. Agents running with the full permissions of whoever provisioned them. The default trust posture for most agent deployments is implicit trust.
NIST has also indicated interest in MCP as a candidate interoperability standard. This matters because MCP has adoption but lacks native identity and authorization. The W3C governance discussions (issue #96 in the MCP governance repo) are directly relevant — and NIST’s involvement could accelerate the timeline for identity-aware MCP specifications.
The practical implication: if you’re building MCP servers today, you need an identity layer that can slot in when the specification catches up. Building without one means retrofitting later, and retrofitting security costs more than designing it in.
The regulatory trajectory is predictable
Legal analysts tracking NIST’s AI standards work have mapped the pattern: voluntary guidelines become industry standards, industry standards become sector-specific regulatory requirements, regulatory requirements become litigation risk.
NIST’s AI Risk Management Framework (AI RMF) moved from voluntary publication to appearing in executive orders and state AI laws within 18 months. That trajectory is compressing.
Industry respondents broadly agree that standards should be technology-agnostic and risk-based. But the comments reveal a tension: industry wants flexibility and optionality; the regulatory trajectory suggests the window for voluntary adoption is shorter than most teams assume.
The precedent from cloud security: NIST SP 800-53 started as guidance, became the baseline for FedRAMP, then the de facto standard for anyone selling to the federal government, then an influence on commercial compliance frameworks. The voluntary period was the window to get ahead of requirements. Agent identity is on the same track.
What NIST’s requirements mean for your infrastructure
Strip away the policy language and the concept paper specifies a concrete set of infrastructure requirements. Most of them are things this site has been writing about for months.
Unique persistent identifiers per agent
Not shared API keys. Not service account tokens that fifteen different agents use. A unique, persistent identifier for each agent instance — tied to the user it acts for, the organization it belongs to, and the permissions it holds. This is identity binding at the protocol level.
Lifecycle management
Agents need provisioning, updating, and revocation — the same lifecycle your IAM system provides for human users. When an employee leaves, their agent’s access should terminate. When a role changes, the agent’s scopes should narrow. When a project ends, the agent’s credentials should be revoked. None of this happens when agents run on shared API keys, because there’s no identity to revoke.
Per-agent scoped permissions
NIST’s authorization requirements align with deny-by-default: agents start with zero permissions and receive only the scopes explicitly granted. The concept paper specifically calls out the risk of agents inheriting their user’s full privilege set — an agent operating autonomously at machine speed should never hold the same trust level as a human making deliberate decisions.
This is scope inheritance with restriction: the agent’s permissions are always a strict subset of the delegating user’s. If the user has tool:crm:read, the agent cannot escalate to tool:crm:write. The principle is already codified in RFC 8693. NIST is validating the pattern at the policy level.
Authenticated inter-agent communication
When agents delegate to sub-agents — and multi-agent architectures are rapidly becoming the norm — every hop in the chain needs authenticated identity propagation. User to orchestrator to sub-agent to tool, with attribution intact at every step. The three-party problem becomes a four-party problem, then a five-party problem. Without identity propagation, you lose the chain after the first hop.
Real-time authorization adaptation
Static roles evaluated at session start don’t satisfy NIST’s requirements. The concept paper describes runtime authorization — per-call policy evaluation that adapts to context, cumulative actions, and changing risk signals. An agent that made three benign CRM queries and then attempts to export the entire contact database should trigger a different policy response on the fourth call.
The infrastructure gap, quantified
Eighty percent deployment, fourteen percent security approval. That gap is an infrastructure problem, not a training or policy problem.
Most agent deployments today use one of three authentication patterns:
- Shared API key — one key for all users, no identity attribution, no per-user audit trail
- Service account — the agent authenticates as itself, not as the user it acts for, breaking the delegation chain
- User token passthrough — better, but typically grants the agent the user’s full permissions with no scope restriction
All three fail NIST’s requirements. Pattern 1 has no identity. Pattern 2 has identity for the wrong entity. Pattern 3 has the right identity with the wrong permissions.
What NIST is describing — and what enterprise deployments need — is a fourth pattern:
// Pattern 4: Delegated identity with scope restriction
import { identifiabl } from "@gatewaystack/identifiabl";
app.use(identifiabl({
issuer: process.env.OAUTH_ISSUER!,
audience: process.env.OAUTH_AUDIENCE!,
}));
// Every agent request now carries:
// req.user.sub → "auth0|8f3a2b1c" (verified user)
// req.user.scope → "tool:crm:read" (restricted scope)
// req.user.org_id → "org_acme_corp" (tenant context)
// agentName → "sales-bot" (agent attribution, via x-agent-name)
Cryptographically verified delegation from user to agent. Scoped to a strict subset of the user’s permissions. Attributed on every call. Revocable independently.
The pattern isn’t new — RFC 8693 has been available since January 2020. What’s new is a federal standards body saying it’s the required pattern.
Prompt injection is an architecture problem
NIST frames prompt injection as an architecture problem, not an input validation problem. The concept paper positions it alongside identity and authorization, not alongside model safety.
This changes where the solution lives. Input validation happens at the application layer. Architecture happens at the infrastructure layer. NIST is saying the defenses against prompt injection belong in the same governance layer as identity and authorization — the control plane that sits between the agent and your backend, independent of the model.
Treat prompt injection as a model problem and the response is better prompting, better fine-tuning, better guardrails inside the LLM. Treat it as an architecture problem and the response is deny-by-default policy enforcement at the gateway, content safety evaluation before the tool call reaches the backend, and identity-attributed audit logging that captures what was attempted and what was blocked.
Don’t wait for finalization
NIST is in the comment period. Finalized standards are months — possibly years — away. But the architectural requirements aren’t going to change directionally. Agent identity, deny-by-default authorization, per-call policy evaluation, identity-attributed audit logging, and authenticated inter-agent communication — these requirements are convergent across NIST, the Cloud Security Alliance, OWASP, and every serious security analysis of agent architectures. The details of compliance will evolve. The architecture won’t.
The builders who implemented cloud security controls before NIST finalized SP 800-53 had compliant infrastructure when the requirements hardened. The ones who waited had remediation projects that cost ten times more. Agent infrastructure is following the same trajectory, on a compressed timeline.
Where to start
Three concrete steps, in order:
-
Audit your current agent authentication. Do your agents use shared API keys, service accounts, or user token passthrough? If any agent request hits your backend without a verified user identity attached, you have the gap NIST is targeting. Understand the identity problem.
-
Implement deny-by-default authorization. No agent should start with permissions. Every capability should be explicitly granted, scoped to a strict subset of the user’s access, and evaluated on every call — not at session start. See what runtime authorization looks like.
-
Build identity-attributed audit trails now. When NIST’s requirements harden, the first evidence your auditor will ask for is an audit trail showing who accessed what through which agent, with policy justification. Retrofitting identity attribution into existing logs is a project; having it from day one is a configuration. What CISOs need to know.
GatewayStack is one implementation of the Agentic Control Plane pattern — JWT-based identity binding, per-call policy evaluation, deny-by-default authorization, and identity-attributed audit logging. It maps directly to the requirements NIST is codifying. It’s not the only way to satisfy them, but it’s a working implementation with production deployments and compliance-ready governance built in.
Get started free · Reference architecture