On September 29, 2026, NIST published a summary of more than 600 responses to its concept paper on software-agent identity and authorization. It also identified the first setting in which it plans to demonstrate the approach: agents working inside a software-development process.
The proposed work will examine how those agents can be identified, authenticated, and authorized. Those are connected tasks, but they answer different questions.
A system can establish which agent is requesting access and still lack a sufficient basis for letting it change a file, release code, or instruct another agent. Successful sign-in does not establish permission for every action that follows.
NIST’s work now turns toward that distinction. When an agent presents a valid identity, what should establish the limits of its authority?
February Established the Program
NIST announced its AI Agent Standards Initiative on February 17, 2026. The initiative supports industry-led standards, interoperable protocols, and research into agent identity, authentication, and security evaluations.
Related work included an agent-security request for information and a draft concept paper on applying identity and authorization practices to agents. The announcement established a program of work, organized in three strategic pillars and producing voluntary guidelines. It did not supply a finished standard that organizations could implement and claim to satisfy.
That boundary remains important when describing the initiative’s progress. Research, stakeholder feedback, proposed demonstrations, and completed guidance provide different kinds of evidence.
The Security Work Identified a Need for Adaptation
On May 18, 2026, NIST published AI 800-5, its analysis of responses to the agent-security request for information. Respondents broadly agreed that agents introduce novel security threats and that established cybersecurity practices remain relevant but need adaptation, and that these security concerns are a barrier to adoption. They identified implementation guidance, information-sharing, and standards as useful government contributions.
For an organization deploying agents, the practical question is where its existing controls stop answering the operational questions.
Consider a hypothetical coding agent helping an engineer prepare an update. The agent needs to read a repository, propose edits, and run tests. Publishing the change to production is a separate operation. Passing work to a second agent creates another point at which the organization must decide what access is necessary.
A credential that permits all of those operations would make access convenient. It would also make the scope of that credential central to the risk. The organization needs to examine the actions it has enabled, including those the original task did not require.
September Identified a First Implementation Setting
In a September 24, 2026 update, NIST’s National Cybersecurity Center of Excellence described plans for Build 3 of its DevSecOps project. The proposed build will explore agents developing, building, and testing code.
The DevSecOps and agent-identity teams will collaborate on identifying, authenticating, and authorizing agents in that environment. It will provide the identity project’s first implementation use case.
This is a meaningful step from defining the problem toward examining it in a particular workflow. The announcement describes work being scoped. It does not report a completed demonstration or establish that the approach has been validated across other deployments.
Software development supplies a concrete setting for the hypothetical distinction. Permission to prepare code, permission to test it, and permission to deploy it can be examined separately. A demonstration can show which information is needed at each step and where a control needs to intervene.
The Comments Sharpened the Questions
The September 29 announcement introduced the NCCoE Agentic AI Identity and Authorization Project Resource Hub and the identity project’s summary of comments. The summary itself states that the observations will inform a future NCCoE project and that NCCoE intends to release a draft project description for feedback.
The published feedback favors building on existing identity standards. NIST plans to test whether those foundations, with extensions and profiles, can support agent deployments.
Commenters also emphasized task-specific authorization, credentials that expire when a subtask ends, and the ability to revoke individual operational tokens without disrupting a persistent identity anchor. They described static or inherited entitlements as insufficient for agents, and called for attenuation so that a subagent never inherits more access than required. These are reported themes from the consultation, rather than newly adopted requirements.
In the hypothetical, the engineer’s broad access need not become the agent’s standing access. The agent preparing a change needs permissions for that work. A second agent reviewing the change needs permissions for its own assignment. An organization should be able to explain why each received the access it did.
That explanation becomes harder if permissions accumulate through a chain of agents or remain active after the task ends. The review therefore needs to follow the actual credentials and operations, rather than stop at the original user’s request.
Reasoning and Permission Need Separate Treatment
NIST’s comment summary describes support for deterministic enforcement and strong opposition to making an LLM the primary or sole authority for authorization. It also records support for a logically separate agent governance component, described as a layer or gateway applied at several points in the architecture rather than a single checkpoint.
The distinction matters in the coding example. The agent might conclude that deploying its change is the best way to complete the assignment. That conclusion does not establish that the engineer or organization permitted deployment.
A control evaluating the request needs information that supports the permission decision. The agent’s explanation can be relevant context. The organization still needs to establish which rules govern and how the result is enforced.
The summary leaves important questions unresolved, including how to represent the intended task, how agents should be identified, and the threat of direct and indirect prompt injection. It also identifies privacy concerns associated with identity, contextual information, and audit records. More traceability can expose more information about the person behind the agent, though commenters proposed zero-knowledge proofs and other privacy-enhancing techniques, including verifiable attribution through privacy-preserving cryptographic proofs.
Records Can Establish Conduct Without Deciding Liability
Commenters sought audit evidence extending beyond a list of completed actions, including delegation chains, policy decisions, intent records, execution evidence, and provenance metadata, together with tamper-evident logging and verifiable evidence chains. As one put it, it is not enough to know that an action occurred. Such records would help reconstruct what happened in a disputed workflow.
If the hypothetical agent releases code without approval, an organization would need to examine who configured its access, what operation it requested, which control evaluated it, and what ultimately executed. A record that the agent signed in would answer only one part of that inquiry.
Those facts can inform legal analysis. They do not automatically allocate liability among developer, platform provider, deploying organization, and user. That question still depends on the applicable law and the conduct established by the evidence.
