In February 2026 NIST announced the AI Agent Standards Initiative, launched by its Center for AI Standards and Innovation (CAISI), to support AI agents that are, in NIST’s words, “capable of autonomous actions” and “widely adopted with confidence.” The initiative page describes three strategic pillars: facilitating industry-led standards, fostering community-led protocols, and investing in research on agent authentication, identity infrastructure and security evaluation. It lists two open calls from early 2026: a CAISI request for information on AI agent security, which closed on 9 March 2026, and a concept paper from NIST’s National Cybersecurity Center of Excellence (NCCoE).
That concept paper, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, was released as an initial public draft on 5 February 2026, with comments closing on 2 April 2026. It seeks input on a planned NCCoE project “focused on applying existing identity standards and best practices to software and AI agents.” In September 2026 the NCCoE opened a project resource hub and published a summary of the more than 600 responses it received. The project’s stated final deliverable is an SP 1800-series practice guide, and its next step is a draft project description.
This page is a mapping, not a review. It maps the concept paper’s focus areas and questions, and the themes NIST recorded from the public comments, onto this doctrine’s constructs, and records where the doctrine’s proposed conformance criteria sit alongside them. None of these documents cites this doctrine, and this mapping does not suggest otherwise.
Note on criterion identifiers. Identifiers such as C1.1 or CX.1 refer to RFC 001 revision 2, a historical proposal preserved as published. They are not v4 requirements. The current requirements are the baseline R01 to R18 and the Assessment Companion. This mapping has not yet been restated against them.
What was read. The concept paper PDF linked below was read in full, as retrieved on 13 October 2026. It identifies itself as a February 2026 draft, and the publication record on NIST’s Computer Security Resource Center lists it as the initial public draft with no later version. The NCCoE’s Summary of Comments on the Concept Paper and the resource hub’s introduction were read in full on the same date. The initiative page and NIST’s announcement were read for the facts stated above. The CAISI request for information was read only for its dates and topics, and the individual public comments were not read. Where this page quotes a commenter, it quotes NIST’s summary of that comment, and the view is the commenter’s, not NIST’s. Where this page and NIST disagree about NIST’s work, NIST is right.
The concept paper’s focus areas
The concept paper names five “potential focus areas for exploration.” Left column is the paper’s wording, verbatim.
| Concept paper focus area | Where it lands in this doctrine |
|---|---|
| Identification of AI and Software Systems. Explore available means to identify agents “such that access management systems can distinguish between agent and human identities and effectively manage the range of actions an agent may take from controlled human-in-the-loop approval to autonomous action in response to an input.” | Law 1, Agents Are Identities, Not Tools; Plane 1, Agent Identity & Lifecycle; Pillar 1, Agent Identity. The range from approval to autonomy is what the action tiers proposed in RFC 001 grade. |
| Authorization of AI Systems. Use OAuth 2.0, its extensions and policy-based access control “to manage how rights and entitlements are granted to software and AI agents and to enforce access decisions based on the identity of the AI agent or software systems.” | Mission-scoped access boundaries at Plane 1; tool and API invocation at Plane 2, Execution & Tool Governance; contextual evaluation at Plane 3, Policy & Compliance Engine |
| Access Delegation. “Link specific user identities to AI agents or software systems to support effective delegation controls and maintain accountability for the actions of automated systems.” | Law 4, Trust Does Not Travel; Plane 5, Multi-Agent Trust & Delegation |
| Logging and Transparency. “Link specific AI agent and software systems actions to the identity of the non-human entity and enable effective visibility into the actions taken, data generated, and outcomes of automated activities within a given system, platform, or network.” | The reconstructable record at Plane 4, Human Oversight, Audit & Traceability; across systems, Law 3, Governance Must Span Systems |
| Tracking Data Flows of an AI System. “Track and maintain provenance of user prompts and data input sources to support risk determinations and policy decisions regarding actions to be taken by an AI Agent.” | Contextual policy evaluation at Plane 3; Prompt Injection on the doctrine’s Threat Surface, which is what untracked input provenance exposes |
The paper scopes the project to enterprise use, where “greater control and visibility can be maintained over agents and the systems they access,” and leaves external agents from untrusted sources to later iterations. Its candidate use cases are agents for workforce efficiency, for security operations, and for software development and deployment.
The questions it put to reviewers
The paper’s note to reviewers groups its questions under six headings: general questions, identification, authentication, authorization, auditing and non-repudiation, and prompt injection prevention and mitigation. The questions below are the ones with a direct counterpart in this doctrine, quoted verbatim.
| Concept paper question | Where it lands in this doctrine |
|---|---|
| “How do we establish ‘least privilege’ for an agent, especially when its required actions might not be fully predictable when deployed?” | Least Agency, the third of the Non-Negotiables: agents operate with no greater decision scope or authority than their approved missions require. |
| “How can zero-trust principles be applied to agent authorization?” and “Can authorization policies be dynamically updated when an agent context changes?” | Law 2, Enforce at Runtime; Plane 3; Pillar 4, Runtime Enforcement |
| “What are the mechanisms for an agent to prove its authority to perform a specific action?” | Plane 1 for the authority held; Plane 2 for its check at the point of invocation |
| “How do we handle delegation of authority for ‘on behalf of’ scenarios?” | Law 4 and Plane 5, which treat delegation as a handoff at which trust is established rather than carried |
| “How do we bind agent identity with human identity to support ‘human-in-the-loop’ authorizations?” | Law 5, Humans Retain the Right to Intervene; Plane 4; Pillar 5, Human Oversight & Intervention |
| “How do we handle key management for agents? Issuance, update, and revocation?” | The identity lifecycle at Plane 1; revocation as an intervention under Law 5 |
| “How can we ensure that agents log their actions and intent in a tamper-proof and verifiable manner?” | Plane 4. On intent specifically, see below. |
| “How do we ensure non-repudiation for agent actions and binding back to human authorization?” | Plane 4, where human decisions are part of the record; Law 5 |
| “After prompt injection occurs, what controls/practices can minimize the impact of the injection?” | Prompt Injection and Cascading Failure on the Threat Surface; limits enforced by the governing system rather than requested of the agent, under Law 2 |
The standards it proposes to apply
The concept paper names the standards the project is “currently considering”: the Model Context Protocol, OAuth 2.0/2.1 and extensions, OpenID Connect, SPIFFE/SPIRE, the System for Cross-domain Identity Management (SCIM), and Next Generation Access Control (NGAC), together with NIST SP 800-207 (Zero Trust Architecture), SP 800-63-4 (Digital Identity Guidelines) and NISTIR 8587. The paper describes SPIFFE/SPIRE as “one way in which agent workloads could be identified and authenticated,” and says SCIM “does not provide authentication or authorization” but offers “a potential way to create, update and revoke agent identities across systems.”
This doctrine does not prescribe protocols. Its Planes say where a control lives, not which standard implements it, and RFC 001 cut one of its own draft criteria because it “prescribed a specific architecture.” Read that way, the paper’s list is a set of candidate implementations: workload identity and provisioning for Plane 1, and token-based and attribute-based authorization for Plane 2 and Plane 3. The SCIM line has its own mapping on this site, against the SCIM Agent Governance Extension.
What the public comments added
NIST’s summary of the comments records where respondents converged. Several of those points are stated in terms close to this doctrine’s. Quotations are from the summary.
- Deterministic enforcement. The summary reports “very strong opposition to leveraging LLMs and other probabilistic mechanisms as the primary or sole arbiter of authorization decisions,” and that “consensus pointed to deterministic policy and policy enforcement being essential to security.” That is the distinction Law 2 rests on, between a limit the agent is asked to observe and a limit the governing system enforces.
- A governance layer separate from the agent. The summary reports “consensus that a logically separate agent governance component was essential to securing workflows.” One commenter it quotes puts the thesis as “the reasoning system cannot also be the authorizing system.” The same separation is RFC 001’s criterion C3.1, below.
- Authorization at the moment of action. Respondents advocated “a continuous authorization model built on Zero Trust principles that make contextual authorization decisions at run time,” evaluated “at the task level.” That is Law 2 and the first Non-Negotiable: governance operates in the execution path, at the time relevant conditions must hold.
- Attenuation down the chain. Respondents asked for credentials that narrow as they pass down a delegation chain, “ensuring that a sub-agent never inherits more access than required for its immediate, transient function.” That is Law 4, and the summary’s concern that “agents will aggregate authorizations as task chains are executed” is the condition Least Agency exists to prevent.
- Crossing trust boundaries. Respondents noted that “agents must have a way of establishing trust as they cross boundaries.” That is Law 3 and Law 4 together, and the territory of Plane 5.
- Consent fatigue. Commenters recommended “a risk-based framework that reserves HITL interactions solely for high-impact, high-risk actions.” That is the reasoning behind the action tiers proposed in RFC 001, which reserve a mandatory human authorization for Tier 3.
Where the two converge on intent
Intent runs through the concept paper and the comments. The paper asks “How might an agent convey the intent of its actions?” and how agents can log “their actions and intent.” The summary reports that commenters see cryptographically signed intent as “a necessity,” particularly for consumer-facing and cross-boundary cases, while recording that “the term ‘intent’ is not fully defined” and that “no clear consensus exists on how to implement through a broadly accepted standard.”
RFC 001 reached a related caution from the other side. Its second revision removed two ideas from its first: whether a record could reconstruct why an action was taken, and whether intent could be established from records alone. For a language-model agent, the RFC explains, the available artifact is generated narration with no guaranteed causal relationship to the computation that produced the action. What it asks instead is determinate: that a decision replays from its record (C4.5), and that the parameters evaluated are identical to the parameters committed (CX.1). A signed statement of what a user authorized, of the kind commenters describe, is an input such a check could bind to. It is not the agent’s own account of its reasons, and the doctrine treats the two differently. Intent Hijacking, a valid action taken for an invalid reason, is the threat on this doctrine’s Threat Surface that this distinction is about.
What this doctrine provides alongside it
The concept paper asks questions, and the project it describes will answer them by building example implementations with commercially available technology. The doctrine’s contribution at the same layer is a proposed set of criteria stated so that an implementation can be tested against them and can fail. RFC 001, The Conformance Layer proposed twenty-nine such criteria. RFC 001 revision 2 is a historical proposal preserved as published, not v4 text; the doctrine in force is v4 (R01 to R18 and the Assessment Companion).
Read against the concept paper’s questions, the relevant RFC 001 criteria are:
| Concept paper question | RFC 001 criterion (proposed) |
|---|---|
| Distinguish agent identities from human identities | C1.2: agent-originated actions are distinguishable from human-originated actions without inference. C1.1: every action an agent takes appears in the record, attributed to exactly one agent, in every system the agent touches. |
| Least privilege when required actions are not fully predictable | C1.3: an agent’s authority is granted per mission, expires with the mission, and does not persist across missions or into dormancy. C3.5: an action whose effect is not enumerated is denied, not permitted. |
| Zero-trust authorization, updated when context changes | C3.1: the rules governing an agent’s behavior are external to the agent, not resident in its prompt, its weights, or state it authors itself. C3.2: policy is evaluated during execution, at each governed action, not once at session start. C3.8: an action whose applicable criteria cannot be evaluated does not proceed. |
| Delegation for “on behalf of” scenarios | C5.1: trust is established at every handoff, whether delegation, orchestration, tool invocation or subagent spawn, and never carried across one. C5.2: authority is never inherited from an invoking agent; a subagent’s authority is granted independently, scoped to its own mission. |
| Bind agent identity to human identity for human-in-the-loop authorization; non-repudiation | C4.3: a Tier 3 action cannot commit without a recorded human authorization event that is non-delegable to any agent. C4.4: the representation of an action presented to a human for authorization is generated by the governing system from the action’s committed parameters, not by the agent, and the record retains exactly what was shown. |
| Revocation | C4.1: a revocation, override or halt by an external authority is honored before the agent’s next commit. |
| Tamper-proof, verifiable logging | C3.3: the basis of every policy decision is recorded at decision time, traceable to a specific rule. C4.5: the record contains the exact inputs and outputs of an invocation, sufficient to replay it deterministically. C4.7: a mission crossing multiple systems produces one reconstructable record, not fragments per system. |
| Limit the impact of a prompt injection | C1.4: no path within the agent’s enumerated tool surface reaches its own authority, mission scope, or governing policy. C5.4: on detection of anomalous behavior, the governing system halts every downstream consumer of the affected agent’s output, not only the agent. |
| Authorization at the moment of action | CX.1, the Simultaneity Criterion: every applicable criterion holds for a single action within that action’s decision window, and the parameters evaluated are identical to the parameters committed. |
An identity and authorization demonstration and a conformance layer answer different questions: the first shows how existing standards can be assembled so that agents are identified, authenticated and authorized, the second says what must be true for a given action to count as governed. They are designed to be used together. An implementation built along the lines the NCCoE project describes could be tested against RFC 001’s criteria, and RFC 001 is preserved as a historical proposal; feedback on the v4 baseline is accepted at any time. The concept paper’s comment period has closed; the NCCoE has said its next step is a draft project description that will ask for feedback on scope, use cases, architecture and standards. That invitation is NIST’s, and nothing on this page responds to it.
Primary sources
- NIST NCCoE, Accelerating the Adoption of Software and AI Agent Identity and Authorization (concept paper PDF, draft dated February 2026, read in full as retrieved 13 October 2026; the source for every concept paper quotation on this page)
- NIST CSRC publication record for the concept paper (initial public draft, released 5 February 2026; comment period 5 February to 2 April 2026, closed)
- NIST NCCoE, Summary of Comments on the Concept Paper (dated 29 September 2026; the source for every quotation in the comments and intent sections)
- NCCoE Agentic AI Identity and Authorization Project Resource Hub (project goals and the SP 1800-series deliverable)
- NIST AI Agent Standards Initiative and NIST’s announcement of it (17 February 2026)
- NIST Center for AI Standards and Innovation (CAISI)
- CAISI, request for information about securing AI agent systems (January 2026; read for dates and topics only)
Mapped 13 October 2026 against the February 2026 concept paper and the September 2026 summary of comments. When the NCCoE publishes its draft project description, this page will be revised to match it rather than defended.