NIST Wants an Identity for the Agent. Authorization Is a Separate Question.

NIST's National Cybersecurity Center of Excellence published this concept paper on 5 February 2026. Moona Intelligence is reading it now, more than six months later, and the first thing worth saying plainly is that this is not new. It is not a finalized standard, and it is not a completed practice guide. It is a draft proposal for a demonstration project, and its public comment window, 5 February through 2 April 2026, closed months before this record was written. What follows treats it as what it is: durable, institutional evidence that a major standards body has decided agent identity and authorization are problems worth a dedicated project, read for what it actually commits to rather than for the breaking news framing a document like this can too easily acquire once it starts circulating again.

What the NCCoE actually published

The National Cybersecurity Center of Excellence, a NIST unit that runs practical, lab based demonstration projects with industry rather than writing pure policy, published Accelerating the Adoption of Software and AI Agent Identity and Authorization as a concept paper: the document NCCoE uses to describe a problem and propose a project before any lab work begins. NIST's own Computer Security Resource Center catalogs the same publication under a fuller title, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, spelling out the abbreviation the NCCoE's own project branding shortens to AI. Both are NIST's own naming of the same document; this record treats the difference as a title variant across NIST's own properties rather than as two separate papers.

A concept paper at this stage is a proposal for public input, not a commitment to a specific technical design. NCCoE opened comment on 5 February 2026 and closed it on 2 April 2026. This record could not establish, in the material available to it, that NIST has yet published a summary of comments received or a decision to proceed to a full practical demonstration guide. What is documented is the proposal stage itself: NIST inviting industry, researchers and practitioners to help shape a project it has not yet built.

Four problems, not one

The paper's own framing, corroborated consistently across its own project material and independent coverage of it, organizes the space into four areas rather than treating agent security as a single control. Identification is about distinguishing an agent from the human user it may be acting for, and about what metadata an agent's identity needs to carry so the systems it touches can scope and bound what it is permitted to do. Authorization is about extending established access control mechanisms, OAuth 2.0 chief among them, so an agent is recognized as its own class of digital principal rather than borrowing a human's standing wholesale. Access delegation is about the link back to whichever human or organizational identity granted the agent its permissions in the first place, built so that accountability survives the delegation and a permission cannot silently propagate further than whoever granted it intended. Logging and transparency is about attribution: making sure a specific action can be traced to the specific nonhuman identity that performed it, and from there back to the human authority responsible for delegating that capability.

Moona Intelligence keeps those four apart deliberately, because the paper itself does. An agent can be cleanly identified and still have no established authorization to do the thing it is attempting. It can be authorized for a class of action and still be operating on a delegation nobody bounded in scope or duration. It can act inside a legitimate delegation and still leave no attributable record if logging was not designed in from the start. Naming four separate failure points, rather than one, is the paper's most durable contribution, independent of whatever technical demonstration eventually follows from it.

Delegation, and where the human sits

The material available to this record describes delegation chains from user to agent as something organizations are expected to bound in scope and duration, rather than leave open ended, and describes an agent's actions as traceable back through its nonhuman identity to the human authority responsible for delegating the permissions it used. That is a specific design goal, not a mechanism this record can describe in technical detail without the primary text in hand. What it establishes at the level this record can verify is the shape of the requirement: a delegation is meant to have a boundary, and an action is meant to be attributable past the agent to the person who authorized it. Whether a given delegation actually respects that boundary, and whether a given log entry actually survives scrutiny, are the demonstration questions the paper proposes to work through, not settled answers it already provides.

Prompt injection as a control problem

One framing choice in the paper's own material is worth stating on its own, because it runs against a common instinct. Prompt injection is treated there as a security control design problem rather than as a model quality issue to be trained away. That framing keeps prompt injection in the same category as the rest of the paper's concerns: something an identity and authorization architecture is expected to limit the blast radius of, through what an agent is actually permitted to reach and act on, rather than something a better model alone resolves. This record could not verify the paper's specific proposed mitigations in enough detail to state them here, and does not attempt to.

Standards under consideration

The paper names a specific set of existing standards and NIST guidance as candidates the eventual demonstration would draw on, rather than proposing to invent new ones from nothing. Among interoperability and access standards: the Model Context Protocol, OAuth 2.0 and its 2.1 revision, OpenID Connect, SPIFFE and SPIRE for workload identity, the System for Cross domain Identity Management, and Next Generation Access Control. Among NIST's own guidance: SP 800-207 Zero Trust Architecture, SP 800-63-4 Digital Identity Guidelines, and NISTIR 8587 on protecting tokens and assertions from forgery, theft and misuse. Naming a standard as under consideration is not the same claim as the demonstration having adopted it, and this record does not read the list as a finished architecture. It reads as the raw material NIST proposes to test against real deployments.

Enterprise use cases, and what sits outside them

The use cases the paper describes are enterprise ones: agents supporting workforce productivity and decision making, security agents operating inside an organization's own environment, and agents automating parts of software development and deployment, including the authorization questions that arise when an automated pipeline can push code or infrastructure changes on its own. The initial scope, consistently corroborated across the material available to this record, is internal enterprise agents an organization already controls and can observe, not agents arriving from outside the organization's own trust boundary. External agents from untrusted sources are explicitly outside the initial effort, though the material describes room for later work to expand into that territory.

Two further exclusions are stated plainly enough to be worth stating here in the same terms. An architecture built only from a large language model and the data it was trained on is treated as outside the scope of the proposed project. So is retrieval augmented generation on its own. Both exclusions point the same direction: the paper is not attempting to govern what a model knows or generates. It is scoped to what an agent, built around tools and the ability to take actions in a system, is permitted to do, and to whom that permission traces back.

What the paper does not establish

It is worth being exact about what this document is not, because a specific and well organized proposal from a standards body is exactly the kind of material that gets cited later as though it settled more than it did. This is a draft concept paper, not a ratified standard. It is a proposal for a demonstration project, not a completed one, and this record could not find evidence that the demonstration itself has begun. It is not enacted regulation, and organizations are not required by anything in it to change how they operate. Its public comment period, open from 5 February through 2 April 2026, has closed, and this record does not treat that closed window as an ongoing invitation. And nothing in the material verified here suggests NIST has evaluated, endorsed, referenced or reviewed any specific commercial product, including Moona's.

The distinction the paper is actually useful for

Strip away the standards list and the use case examples and the paper's most durable contribution is structural rather than technical. It treats an agent's identity, its authorization to perform a specific action, the delegated human authority it is acting under, and the auditable record of what it did as four separate concerns, not stages of one problem that identity alone resolves. An agent can be identified without being authorized. It can be authorized for a class of action without a bounded delegation behind it. It can act inside a legitimate delegation and still leave no attributable trail if logging was never designed in. Establishing who or what an agent is does not, on its own, answer whether the specific action it is proposing right now should be allowed to proceed. That is a different question, and the paper's own four part structure keeps it separate rather than folding it back into identity.

Where this sits against Moona's own coverage

Estonia's Eesti.ai advisory board proposed a distinct national identity for agents in June 2026, a government backing a specific identity mechanism. China's joint implementation opinion, issued in May 2026, allocates decision rights into three classes bounded by what a user authorized, policy guidance rather than a standards body's technical proposal. Neither is the same kind of document as this one. NIST's concept paper is narrower in one sense, it proposes a demonstration project rather than committing to a national identity system or issuing binding policy, and broader in another, because it names identification, authorization, delegation and auditing as four distinct problems rather than folding them into a single mechanism. That four part structure is the same separation this desk has kept finding independently reinvented, from GitLab's composite identity authorizing the intersection of a human role and a service account role to Okta's Cross App Access separating who may connect an agent to a resource from what the represented employee already had access to to Nuggets documenting an agent's authority as cryptographically linked to a human while leaving that human's own mandate to grant it undocumented. A standards institution naming the same separation as a formal project scope is corroboration that the distinction is real, not evidence that any of those implementations, or Moona's own, has already resolved it.

What we could not verify

Every NIST hosted destination for this record, nccoe.nist.gov, csrc.nist.gov and nist.gov alike, including the concept paper PDF itself, was blocked by this session's network egress policy on every attempt. No NIST hosted page could be fetched directly. What is stated above rests on repeated, independently phrased searches whose results were consistent with each other across separate queries and across independent outlets describing the same document, including its title, publication date, comment period, four stated focus areas, named standards, enterprise use cases and stated scope exclusions. This record does not state the paper's authors or editors, because that detail was not corroborated in the material available to this session. It also does not attribute specific sentences, quotations or numbered requirements to the paper's text, because none could be independently confirmed without reading the document directly. An editor with unblocked network access should read the concept paper PDF directly before any claim beyond what is verified here is added to this record.

What this record does not claim

NIST has not reviewed, evaluated or referenced Moona in any material available to this record, and nothing here should be read as institutional validation of any specific vendor, Moona included. Nor does this record treat identity, authorization, delegation and auditing as a stack any single product, Moona's or otherwise, already fully implements. The paper names four separate problems a standards body considers worth a demonstration project. That an institution has named them is the evidence this record verifies. Whether any given system actually solves them is a separate, unresolved question the paper itself leaves open, and so does this record.