A federal standards body does not publish a concept paper for fun. It publishes one because it expects the result to become the thing everyone else measures themselves against.
That is what is happening right now with AI agent identity. The National Institute of Standards and Technology, through its National Cybersecurity Center of Excellence, is building a standards project called Software and AI Agent Identity and Authorization. It sits inside NIST's wider AI Agent Standards Initiative, and its stated goal is to show enterprises how to identify, authenticate, and authorize software agents using controls that already exist in identity and access management. The project has moved past the concept stage. NIST received more than six hundred public comments, and as of late September it was standing up the formal project, with a webinar on October 28 walking through the first real implementation use case.
Most coverage of AI agent identity this year has come from a different direction. A widely cited industry report framed identity sprawl among machine accounts as an authorization crisis, built from a vendor's own survey of security and risk teams. That argument is useful, but it describes a market problem. Vendors surveying their customers about a gap those same vendors sell tools to close is a familiar pattern, and it says nothing about what a regulator or an auditor will later treat as the baseline. What NIST is doing is a different kind of event entirely. It is the federal government's own standards body, the one agency whose frameworks have a documented history of migrating into executive orders, state statutes, and procurement contracts, formally working out how agent identity and authorization should look.
For a chief information security officer or a chief compliance officer, that distinction changes the question being asked. The question is no longer whether agent identity controls are a good idea. It is whether an organization can show, when asked, how its approach lines up with the direction a federal standards body is already moving. This post walks through what the NCCoE concept paper actually proposes, how it differs from vendor-survey arguments about identity sprawl, and what to have ready before the practice guide ships.
The document driving all of this is titled Accelerating the Adoption of Software and AI Agent Identity and Authorization, and the concept paper is more specific than a typical policy discussion draft. It defines an agentic architecture as a system that takes an instruction, pulls in context from other resources, processes the result, and possibly acts on it before returning a response. Retrieval-only systems and plain large language model chat are explicitly out of scope. So are external agents from untrusted sources, at least for this first round. The focus is enterprise agents that an organization deploys and controls.
NIST proposes five areas a future project would need to address. Identification covers how an agent gets a persistent or task-bound identity, separate from the human or service account that launched it. Authorization covers applying OAuth 2.0 extensions and policy-based access control to decide what an agent may do in a given moment, not just what it was provisioned to do at setup. Access delegation covers the chain connecting a human's authority to the actions an agent takes on that human's behalf. Logging and transparency covers whether a record names the agent that acted, not a shared credential standing in for it. Data flow tracking covers keeping provenance on the prompts and data an agent pulls in, so a policy decision can account for where information came from.
Three use cases anchor the early thinking: enterprise agents built for workforce productivity, enterprise agents built for security operations, and agents embedded in software development and deployment pipelines. The NCCoE project page describes the eventual output as a practice guide, built from example implementations in NCCoE labs using commercially available technology, following the same iterative release model NIST used for its Mobile Driver's License work. That is a meaningful signal. A practice guide with working reference implementations is not a thought exercise. It is the kind of document procurement teams cite and assessors ask about.
It is worth being precise about why this is a different kind of development than the identity sprawl reporting that has circulated this year. A vendor survey of security leaders, however large the sample, measures sentiment and self-reported practice among a group of customers and prospects. It can be directionally useful, and it is not the same thing as a government agency publishing its own working definition of what good agent identity and authorization looks like. One shapes talking points. The other shapes what gets written into the next assessment checklist.
This matters because of how NIST documents tend to travel. The NIST blog post on agent identity makes the underlying argument explicit. Credential sharing between an agent and the human or service account it runs under is, in the authors' words, a bad idea in every context, because it erases the accountability a non-human identity governance program depends on. Bonfy has made a version of this argument before, writing about the gap between knowing who accessed a system and knowing identity and intent. The difference now is that the same observation is coming from the agency whose frameworks regulators cite.
Static long-lived credentials, bearer tokens, and shared service accounts are the pattern NIST wants enterprises to move away from, in favor of short-lived, narrowly scoped tokens tied to a specific agent and task. That is a harder architectural change than publishing a policy memo, and it is exactly the kind of change that benefits from a reference architecture to build toward rather than inventing one from scratch per deployment.
One detail worth emphasizing for technical and compliance audiences alike is what NIST is not doing. It is not asking the industry to invent a new identity protocol for agents. The concept paper leans on standards that already exist and are already deployed at scale.
OAuth 2.0 and its extensions anchor most of the authorization discussion, largely because Model Context Protocol, the connector standard agents use to reach tools and data, already relies on OAuth for its authorization flow. OpenID Connect supplies the identity layer on top, carrying authentication and consent information alongside an access decision. SPIFFE and SPIRE, built originally for workload identity in distributed systems, are offered as a way to give an agent a cryptographically verifiable identity independent of whatever human or pipeline launched it. SCIM handles the provisioning and deprovisioning lifecycle so an agent identity does not outlive the task it was created for. Next Generation Access Control, an older NIST specification for attribute-based access control, is proposed as the policy engine that can evaluate an agent's request against a graph of users, resources, and context rather than a static permission list.
That list should sound familiar to anyone who has read about the data layer access control argument, and it overlaps closely with how Bonfy has described the MCP OAuth flaw exposing weak agent trust assumptions earlier this year. NIST is not contradicting that work. It is formalizing the same direction with federal weight behind it, which is precisely why it changes the compliance conversation rather than just adding to it.
Translate the concept paper's five focus areas into questions a compliance or audit function will eventually ask, and the shape of future evidence requests becomes clearer. Can you name the agent, not the service account, that performed a given action? Can you show the authorization decision that let it act, and the policy behind that decision, at the moment it happened rather than reconstructed afterward? Can you trace a delegated action back to the human or workflow owner who authorized the agent to act on their behalf? Does your logging distinguish agent activity from the human activity it rides alongside? Can you show where the data an agent used in a decision came from?
Every one of those questions maps directly onto a known weak point. The Kiteworks analysis of agents that are logging in as humans covers exactly how shared credentials defeat the first and fourth questions before an investigation even starts. Bonfy's writing on relationship-aware governance, not just data classification, speaks to the fifth. None of these are new problems. What is new is a federal agency compiling them into a single framework that an assessor can eventually point to and ask an organization to measure itself against.
Treat the five areas as a checklist worth running internally now, long before any final guidance appears. An organization that can answer all five questions today is not waiting for NIST to tell it what good practice looks like. It already has the evidence a future assessment will ask for.
This is not a paper sitting on a shelf while NIST digests six hundred comments. By late September, an October webinar update confirmed that the agent identity and authorization project is being implemented inside NCCoE's existing Secure Software Development, Security, and Operations practice. The third build of that project, covering agentic AI in software development pipelines, is the identity project's first real implementation use case. A public webinar on October 28 covered the scope of that work and brought in industry collaborators to discuss agentic AI's role across the software development lifecycle.
That pairing is not incidental. CI and CD pipelines are among the clearest cases of an agent acting with real authority inside a production environment, touching source code, build artifacts, and deployment credentials with limited human review per action. It is also one of the three use cases the original concept paper named. Choosing it as the first implementation says NIST intends to produce working reference architectures, not abstract guidance, and that those architectures will cover exactly the kind of governed agent orchestration enterprises are already trying to build on their own, without a shared blueprint.
Organizations running agentic pipelines today, or planning to, have a narrow window to watch this work closely rather than discover it after a practice guide publishes. The November 9 comment deadline on the updated DevSecOps materials is a near-term opportunity to shape that output rather than simply inherit it.
Here is the pattern that should concern anyone whose job involves defending a control decision after the fact. NIST's AI Risk Management Framework, released in January 2023, was voluntary and non-binding on the day it shipped. Within roughly eighteen months it was showing up in executive orders, state AI statutes, and federal procurement language. Legal commentary on the current agent identity effort, including the Jones Walker analysis, draws that comparison directly and expects a similar arc here, with sector guidance beginning to appear by the end of this year and regulatory incorporation starting in 2027.
That timeline matters because of how liability questions get argued. When a regulator, an auditor, or opposing counsel asks why an organization's AI agents could act without clear identity or scoped authorization, "there was no standard yet" is a credible answer only until a credible standard exists. Once NIST publishes a practice guide with working reference implementations, that defense collapses into a different and much harder question. Why did your organization's approach differ from the federal reference, and can you show that difference was a deliberate, documented risk decision rather than an oversight.
This is also where NIST's own existing material already works against the "no standard" defense today, not just in the future. The NIST Cybersecurity Framework and the agency's broader guidance on NIST CSF compliance already establish that identity governance and access control are baseline expectations for any sensitive system, agentic or not. The agent-specific concept paper narrows that general expectation into something concrete enough to audit against. Naming an owner for an agent on an org chart was never the same as controlling what it could reach, a point Bonfy has made in writing about the AI governance accountability gap, and NIST's work gives that argument a federal citation to point to.
None of this requires waiting for a final NIST publication to start acting. A handful of concrete steps put most organizations ahead of where the practice guide will eventually expect them to be.
Build an inventory first. List every production and pilot agent, the identity it currently uses, and whether that identity is unique to the agent or borrowed from a human or shared service account. This is the same exercise other regulators have already asked for in adjacent contexts, and it tends to reveal more gaps than anyone expects.
Map your authorization model against the five focus areas above rather than against a generic access control policy. Note where an agent's permissions are static versus where they adjust based on context, and document which gaps are deliberate risk acceptances and which are simply unaddressed.
Prioritize short-lived, scoped credentials over static API keys for any agent with access to sensitive data, and insist that logging capture agent identity and intent, not just the account that technically made the call. The Kiteworks research on agents that outlive revoked credentials is a useful stress test here. If revoking a human's access does not reliably cut off every agent acting under that authority, the delegation chain is not documented, it is assumed.
Push enforcement to the point where data leaves a system rather than relying only on upstream permission grants. That is the argument behind continuous control as a design principle, and it lines up closely with how Contextual Data Enforcement evaluates each request against the entities and context involved, rather than trusting that a permission granted months earlier still matches today's task.
Finally, decide whether your organization is positioned to comment on future NCCoE drafts as they circulate, or at minimum to track the webinar series and summary of comments NIST is publishing. Six hundred responses already shaped this project once. Organizations with working implementations to describe are in a stronger position to shape the practice guide than ones that wait to read it after publication.
To learn more about agent identity governance, schedule a custom demo.
It is a document published by NIST's National Cybersecurity Center of Excellence in February 2026, titled Accelerating the Adoption of Software and AI Agent Identity and Authorization. It explores how existing identity standards and access control models should apply to software and AI agents that act with limited human supervision, and it asks the public detailed questions about identification, authentication, authorization, delegation, auditing, and prompt injection. The paper proposed a potential future NCCoE project built around five focus areas, and NIST has since moved forward with standing that project up.
No. The concept paper and the project it is building toward are voluntary guidance from a standards body, not a regulation. What makes it significant is NIST's track record. Its AI Risk Management Framework was also voluntary on release and was referenced in executive orders, state statutes, and procurement requirements within about a year and a half. Legal commentary on this initiative expects a similar path, with sector-specific guidance appearing before the end of this year and formal regulatory references beginning in 2027.
No new protocol is being invented. The concept paper and NIST's related guidance point to OAuth 2.0 and its extensions, OpenID Connect, SPIFFE and SPIRE for workload identity, SCIM for lifecycle management, and Next Generation Access Control for attribute-based authorization decisions. The approach is to adapt standards that already secure human and machine identity in other contexts, rather than ask the industry to adopt an entirely new agent-specific protocol.
Reports built from a vendor's survey of its own customers describe a market perception problem, useful for understanding sentiment but not a statement of what a regulator or auditor will eventually expect. This NIST work is the federal government's own standards body defining a reference approach, with a published concept paper, more than six hundred public comments, and an active implementation already underway inside an existing NCCoE project. One is evidence of how security teams currently feel about a problem. The other is evidence of where the compliance bar is heading.
Build a current inventory of every agent in production or pilot and the identity each one uses, then map authorization and logging practices against the concept paper's five focus areas, identification, authorization, delegation, logging, and data provenance. Move agents off shared or static credentials where possible, and make sure logging names the agent and its authority rather than the account it rides on. Teams that can already answer these questions will be better positioned when a formal practice guide arrives than teams starting from scratch.