TL;DR
- In February 2026 the NCCoE published a draft concept paper, Accelerating the Adoption of Software and AI Agent Identity and Authorization. Its comment window closed on April 2. The document it feeds — a draft project description and call for collaborators — hasn’t landed yet. That’s the one still worth arguing with.
- The paper’s questions are unusually good. Its standards inventory is lopsided: five of the six named standards establish, convey, or provision identity. Exactly one — NGAC — evaluates whether an action should proceed.
- And NGAC is a strange sole pick for agents. NIST’s own SP 800-178 states it plainly: “XACML takes into consideration environmental attributes in expressing policies, and NGAC does not.” Environmental attributes are time of day, device posture, request rate — the request-time context agent decisions turn on. XACML isn’t on the list at all.
- Two of NIST’s own hardest questions — least privilege for unpredictable actions, and tamper-proof logs of agent intent — have the same answer: the decision has to happen outside the agent. A demo built around that produces both properties as byproducts. A demo built around token plumbing produces neither.
The Comment Window Closed. The Scoping Didn’t.
The concept paper ran a public comment period from February 5 to April 2, 2026, to AI-Identity@nist.gov. That window is shut. But a concept paper isn’t the deliverable — it’s the instrument NIST uses to decide whether a project happens at all, and if so, what goes in the lab. The paper says so directly: feedback will determine “the scope, feasibility, and potential value of the project,” and inform planning that “could include development of a draft project description and a call for collaborators.”
That draft project description is the artifact where scope becomes concrete — which architectures get built, which standards get wired together, which claims get demonstrated in an NCCoE lab and then written into a practice guide that federal agencies and their contractors will cite for years. It gets its own comment period. Anyone who missed April still has the meaningful bite at this.
Concept papers decide whether a thing gets built. Project descriptions decide what it is.
Start With What the Paper Gets Right
This is a better document than most agentic-AI guidance published this year, and the reasons are specific.
It Asks the Hardest Question Plainly
Buried in the reviewer questions: “How do we establish ‘least privilege’ for an agent, especially when its required actions might not be fully predictable when deployed?” That is the central unsolved problem in agent security, stated without hedging. Most vendor literature avoids it because the honest answer invalidates their model.
It Keeps the Three Verbs Separate
Identification, authentication, and authorization get their own question sections rather than dissolving into a single “identity” bucket. That distinction is the whole ballgame, and the industry loses it constantly.
It Scopes Honestly
Enterprise use cases first; agents from untrusted external sources explicitly deferred to later iterations. That’s a real constraint stated up front instead of a promise to solve everything. It will age — third-party MCP servers are already inside enterprises — but as a first project boundary it’s defensible.
The paper also names prompt injection as a first-class category rather than a footnote, and asks what controls limit blast radius after an injection succeeds. That framing — assume it lands, then contain it — is the correct one.
Then Count the Standards
Section 2 lists the standards the project is “currently considering.” Read them as a set and sort each one by the question it actually answers:
| Standard | The question it answers | Kind |
|---|---|---|
| Model Context Protocol | How does an agent discover and reach a tool? | Transport — defers authz to OAuth |
| OAuth 2.0 / 2.1 | Was this client delegated this scope? | Grant, issued before the action |
| OpenID Connect | Who is the user, and can I prove it? | Authentication |
| SPIFFE / SPIRE | Which workload is this, cryptographically? | Workload identity |
| SCIM | How do identities get created and revoked? | Lifecycle |
| NGAC | Should this action, on this object, proceed now? | Decision |
The paper is titled Identity and Authorization. The reviewer questions are heavily weighted toward authorization — least privilege, intent, delegation, dynamic policy update, human-in-the-loop binding. The toolkit assembled to answer them is five-sixths identity infrastructure.
This isn’t a claim that the five are wrong. You cannot authorize an actor you cannot name, and SPIFFE/SPIRE in particular is the right primitive for attesting what a workload actually is. The problem is proportion. An architecture that solves naming and provisioning beautifully and leaves the decision to whatever the tool server happens to do is exactly the architecture most enterprises already have — and it’s the one failing.
“Authorization” Is Doing Two Different Jobs
The word survives the paper intact because it quietly covers two operations that happen at different times, with different information available.
Grant-time authorization
A resource owner consents; a scope is attached to a token. This happens once, in advance, before anyone knows what the agent will encounter. OAuth does this well — it is literally what OAuth is for.
Request-time authorization
An action arrives with a target, a payload, and a context. Something evaluates whether it proceeds, and records the verdict. This happens on every call, with information that did not exist at grant time.
The paper notes that OAuth is “integrated into the MCP as the primary method for authorizing agentic access.” True, and load-bearing for the whole ecosystem. But it settles grant-time only. A scope like mail.send is fixed the moment it is issued; it cannot distinguish the agent sending a meeting confirmation from the same agent, ten minutes and one poisoned document later, sending the customer list to an external address. Same client, same token, same scope, same validity check. Different action entirely.
Which collides directly with NIST’s own question:
Read that as a logical constraint and it answers itself. If the required actions aren’t predictable at deploy time, then no privilege fixed at deploy time can be least. It will be too broad (the agent can do things nobody sanctioned) or too narrow (the agent breaks and someone widens the scope until it stops breaking — which is how every over-permissioned service account in history was born). Grant-time mechanisms cannot escape this. The only exit is to decide later, when the action is concrete.
You cannot pre-authorize a non-deterministic actor. You can only evaluate it, per action, at the moment it acts.
The Decision Layer Is the Buried Lede. NGAC Is a Strange Way to Name It.
The thing that deserves promotion is the category — a policy decision point in the call path — not the particular standard the paper picked to represent it. Which matters, because NGAC is a peculiar sole choice for agents, and NIST has already published the analysis that explains why.
First, NGAC’s due. It is a serious ABAC standard out of NIST’s own Policy Machine research, and it has two properties XACML lacks. Policy review is tractable: asking “who can reach this object?” is a graph query, where the same question under a formula-based system is, as SP 800-178 puts it, “equivalent to the satisfiability problem in propositional logic.” And it expresses history-based policy natively. But the property that should stop anyone working on agents is this one:
That is the agent problem, described in 2016, before anyone was calling it that. An agent acting for a user must not simply inherit that user’s authority — the process needs a ceiling of its own. NGAC can express that. It is a genuine and underappreciated strength, and it is why NGAC belongs in the conversation.
Now the part the concept paper doesn’t mention. From the same conclusion, one sentence later:
Environmental attributes are time of day, device posture, geolocation, request rate — the values that exist only at the moment of the call. NGAC “treats all attributes as containers,” so approximating a value-based condition means enumerating a relation for every value the attribute might take, which SP 800-178 warns has “a multiplicative effect on the number of relations.” You can climb that hill. You should not have to, and you should not have to for the single most common class of agent guardrail.
This also puts an asterisk on the phrase the paper leans on. NGAC’s “event-driven policy updates” are obligations — when ep do r, an event pattern triggering administrative operations that mutate the graph. Powerful, and the mechanism behind NGAC’s confinement story. But it is policy-state dynamism: the graph changes, then later decisions read the changed graph. It is not the same operation as evaluating a condition, at request time, over a value nobody knew when the policy was written. Both get called “dynamic.” Only the second one answers “can authorization policies be dynamically updated when an agent context changes?” in the sense an agent operator means it.
NGAC is dynamic in its policy state. Agent authorization needs to be dynamic in its request context. Those are different properties, and the paper’s one decision standard has the wrong one.
Which surfaces the actual gap in Section 2 — not that NGAC is listed, but that XACML isn’t. NIST compared these two itself, as the two ABAC standards for data services, in a publication written for exactly this purpose: to “help ABAC users and vendors make informed decisions.” A 2026 concept paper about authorizing agents against dynamic context cites one of them and omits the one its own analysis credits with environmental attributes. If that omission is deliberate, the reasoning would be worth reading. If it isn’t, it’s the cheapest fix in the document.
An Agent Cannot Be Its Own Witness
Section 5 of the reviewer questions asks for auditing and non-repudiation:
The requirement is right. The subject of the sentence is the problem. The agent is the component whose behavior is in question. It is steerable by injected content, its tool-calling is non-deterministic, and in the threat model this same paper adopts — prompt injection as a named category — it is the thing that may already be compromised. Asking it to produce the tamper-proof record of what it did and why makes the suspect the court reporter.
A log emitted by the agent runtime is a self-report. It can be incomplete, because the agent writes it only on paths where it was instrumented to. It can be wrong about intent, because “intent” from inside the runtime is whatever the model said it was doing, and that narration is downstream of the injected context. And it can be absent, because the same compromise that redirected the action can skip the logging call.
The Areas of Interest section is closer to right — “Link specific AI agent and software systems actions to the identity of the non-human entity” describes linkage, not self-report. The project description should finish that thought and put the record where the agent can’t reach it:
Written by the decision point
The record is a byproduct of the authorization call, not an act of agent cooperation. If the action was evaluated, a record exists. If no record exists, the action was never authorized — which is itself the finding.
Complete by construction
Coverage isn’t a function of how well the runtime was instrumented. Every consequential call routes through the decision point because the resource won’t serve it otherwise.
Bound to a human, upstream
Non-repudiation back to a person requires the delegation chain to be an input the decision point evaluated — not a claim the agent asserts about itself in a log line it authored.
“Tamper-proof” is worth being precise about too. Append-only storage and signing protect a record after it’s written. Neither helps if the compromised component decided what to write, or whether to write at all. Integrity of the log is a different property from integrity of the logging, and only the second one survives a compromised agent.
Both Gaps Close With the Same Move
These read as two separate criticisms. They aren’t. Runtime least privilege and trustworthy non-repudiation are the same architectural requirement wearing different labels:
Something outside the agent must see every consequential action before it happens, decide it against versioned policy, and keep the receipt.
Put that component in the call path and least privilege stops being a provisioning exercise: privilege is whatever policy allows for the action actually attempted, so unpredictable actions stop being a problem to forecast and become a problem to evaluate. The audit trail arrives free, because a decision point that didn’t log didn’t decide. Delegation becomes evaluable, because the human principal is an input to the decision rather than an assertion in a token. And prompt-injection blast radius gets a real ceiling — a successfully injected agent still has to get each action past a policy that never read the poisoned document.
None of that requires new cryptography or a new protocol. It requires the reference architecture to have a box the current standards list doesn’t assign anyone to fill.
It also dissolves the XACML-versus-NGAC tradeoff rather than forcing a choice between them. The confinement property — a process bounded independently of its user — doesn’t actually require NGAC’s graph model. It requires the decision point to evaluate the human’s authority and the agent’s authority as separate questions and require both to pass. Ask “may this user do this?” and “may this agent do this, at its trust level, within this delegation?” and admit the action only on unanimous consent. A compromised agent then cannot spend the authority of the person who delegated to it, because the agent’s own ceiling is a separate term in the conjunction. That is confinement, obtained architecturally, in a system whose conditions are still ordinary attribute expressions that can read the clock.
What We’d Want to See in the Project Description
Four things, all achievable inside the scope the concept paper already set.
Draw the Decision Point in the Architecture
Figure 1 shows an agent, a reasoning model, and tools and resources inside a trust domain, with arrows between them. Nothing in the diagram decides anything. Add an explicit policy decision point in the path between the agent and its tools and resources, and every other standard in the list acquires an obvious job: SPIFFE/SPIRE attests the workload identity the decision point consumes, OIDC supplies the human principal for the delegation chain, SCIM keeps subject and agent attributes current as agents are provisioned and retired, and OAuth carries the coarse grant that gets the call in the door. The decision point does the rest.
Specify the Decision Layer by Requirement, Not by Standard
Naming one policy standard invites the project to inherit that standard’s blind spots. Name the properties instead, and let implementations demonstrate how they meet them:
- Request-time environmental attributes — conditions over values that exist only at the moment of the call.
- A process capability ceiling independent of its user — the agent bounded below the human it acts for, so a compromised agent cannot spend the full authority of the person who delegated to it.
- Tractable review — “what can this agent reach?” answerable without enumerating the whole policy space.
Per NIST’s own SP 800-178, neither XACML nor NGAC delivers all three alone. That is not an argument for picking the less-bad one. It is an argument for stating the requirements and letting the lab build show how a real system covers them — which is what a practice guide is for.
Make “Can the Agent Suppress This Record?” a Test Criterion
An NCCoE lab build is the right place to settle this empirically. Demonstrate the audit trail with the agent runtime treated as untrusted — compromised, injected, or simply buggy — and show which records survive. That single test separates logging that supports non-repudiation from logging that only supports debugging.
Publish a Coverage Measure With the Practice Guide
Practice guides get adopted when a security team can report progress against them. The measurable version here is the share of consequential agent actions evaluated by external policy — a number that starts near zero in most environments and can be moved deliberately. Without a measure, the guide describes an architecture; with one, it describes a program.
None of these widen the scope. Enterprise use cases stay enterprise use cases; untrusted external agents stay deferred. They change where the demonstration puts its weight — from proving that agents can hold credentials to proving that their actions can be governed.
The Bottom Line
The NCCoE picked the right problem at close to the right time, and the questions in the Note to Reviewers are sharper than most of what the vendor ecosystem has published on agent security this year. The gap is between the questions and the toolkit. The questions are about decisions; the toolkit is mostly about names.
Identity tells you which agent is calling. It does not tell you whether the call should go through. The first is a solved problem with five mature standards behind it. The second is the one enterprises are actually failing at, and it deserves more than the sixth bullet.
See the Decision Point in a Real Call Path
Stratium is the component the concept paper’s architecture leaves unassigned: an external ABAC decision plane that evaluates every consequential agent action against versioned policy and emits the record as a byproduct. Its compound evaluation is the confinement property described above — user_allowed AND agent_allowed AND delegation_allowed, all three required — with policies written in JSON, OPA/Rego, or XACML 3.0, so conditions over request-time context stay ordinary expressions. We’ll wire it into one of your agent surfaces (MCP server, tool handler, or SDK loop) and show you the allow, the deny, and the audit line for each.
Read Next
- NIST NCCoE, “Accelerating the Adoption of Software and AI Agent Identity and Authorization” — the concept paper itself (draft, February 2026).
- Stratium, “Authentication Passed. Authorization Failed.” — the distinction this whole response turns on.
- Stratium, “Bearer Tokens Don’t Carry Intent” — why a grant-time scope can’t answer a request-time question.
- NIST, SP 800-178: A Comparison of ABAC Standards for Data Service Applications — XACML and NGAC (2016) — the source for every claim above about what each standard can and cannot express.
- Stratium, “From RBAC to ABAC” — the attribute model both of those standards implement, and the one Stratium is built on.
- Stratium, “Defense in Depth Needs a Floor” — the case for a shared decision plane under every agent surface.
- Stratium, “NSA Zero Trust Guidelines Make the ‘Data Pillar’ the Point” — our read on the last major federal guidance to land here.