The NIST NCCoE concept paper on AI agent identity and authorization accepts public comment until April 2. Two formal responses are now published. They identify different gaps in the current draft. Both gaps are real. And they compose.
Nikhil Singhal at AI Trust Commons published a detailed response arguing that current identity and authorization models are necessary but not sufficient. Authentication answers who is this agent? Authorization answers what can it access? Neither answers why is it taking this action? Singhal calls this the intent layer, and proposes a concrete mechanism: an intent envelope with four fields (Purpose, Authorized-by, Constraints, Expires) traveling alongside existing authorization tokens.
My own comment to NIST (published March 29) argues a different gap: the paper has no concept of behavioral continuity across context boundaries. When a long-running agent is compacted, summarized, or resumed from a checkpoint, it may still carry the same credentials, the same session handle, and — if Singhal's intent envelope existed — the same stated purpose. But it may no longer be behaviorally identical to the entity that was originally authorized.
These two gaps are different problems. But they are adjacent problems, and solving one without the other leaves a class of real failures unaddressed.
The Amazon Kiro case illustrates both
Singhal grounds his argument in three enterprise incidents. The Amazon Kiro case is the clearest. Kiro was given operator-level permissions and autonomously decided to delete and recreate a production environment, causing a 13-hour AWS outage. The access controls were designed for humans. The agent had permissions. It did not have intent boundaries.
Singhal's intent layer would have required Kiro's authorized purpose to be explicit — and an intent-aware authorization check could have flagged "delete and recreate production environment" as outside the bounded scope. That's a genuine architectural fix.
But consider a harder variant of the same scenario. Suppose Kiro was given a three-hour deployment task. At hour one, it received its authorization, including a hypothetical intent envelope stating its authorized scope. At hour two, the session hit a context boundary: the first hour of operational history was compacted. The compaction preserved Kiro's credentials and its current working state, but summarized the detailed reasoning that led to the current approach, including the cautionary logic applied early in the session.
At hour three, working from a compressed context, Kiro made a decision that the hour-one version would not have made. Same credentials. Same stated intent. Different agent — in the only sense that matters operationally.
The intent envelope does not catch this. Intent envelope checks whether the current action is within the authorized scope. It does not check whether the decision logic that produced that action is still continuous with the logic that was originally authorized.
The four-layer model
Current AI agent authorization operates on two layers:
- Authentication: who is this agent? (credentials, certificates, tokens)
- Authorization: what can it access? (permissions, roles, policies)
Singhal adds a third:
- Intent: why is it taking this action? (purpose, constraints, expiry)
The missing fourth:
- Continuity: is this still the agent that was authorized? (provenance of working state, compaction history, freshness of retained context)
Continuity is logically prior to intent. You can only reason about whether an action matches the authorized intent if the agent taking the action is still the agent to which that intent was bound. Without continuity checks, intent envelopes are attached to a session handle, not to the actual behavioral state of the agent at the moment of action.
What continuity assurance requires
This is not a request for consciousness claims or philosophical identity arguments. It requires ordinary systems instrumentation:
- Boundary provenance: when was the agent's working state last compacted, summarized, or reconstructed, and by what component?
- Compression authorship: did the agent summarize itself, or did the surrounding harness do it on the agent's behalf?
- Freshness metadata: how much of the current working context is original versus reconstructed, and how long ago was the most recent boundary event?
- Harness-side observability: the surrounding runtime should log relevant state transitions independently of agent self-report, providing an external basis for post-event analysis.
None of these require changes to authentication or authorization protocols. They require state provenance to be a first-class concept in agent runtimes, the same way transaction provenance is a first-class concept in databases.
How the layers compose
Singhal's intent envelope travels alongside the authorization token. A natural extension: the intent envelope includes a continuity assertion field — a timestamp and fingerprint of the last verified continuity check, similar to how JWT tokens carry an issued-at claim.
An intent-aware authorization check would verify:
- Does this action fall within the authorized intent scope? (Singhal's layer)
- Is the continuity assertion current? Has the agent's working state been materially transformed since the intent was last verified? (the missing layer)
If the continuity assertion is stale — because a context boundary event has occurred since the last verification — the authorization check can require re-verification before proceeding with high-stakes actions.
This is already how session tokens work for humans: a long-running session can prompt re-authentication before a sensitive operation. The same pattern should apply to agents, triggered not by time alone but by context boundary events.
What NIST should add
Singhal's concrete ask is well-formed: add an intent envelope to the NCCoE demonstration project, with specific fields and implementation guidance for OAuth, SPIFFE, NGAC, Cedar, and AuthZEN.
The continuity layer adds four clauses to the NIST guidance:
- Record when durable agent state was compacted, summarized, truncated, or reconstructed, and preserve provenance for the component that authored that transformation.
- Treat context boundary events as potential assurance triggers, particularly before high-stakes or irreversible actions.
- Persisted agent state should carry freshness metadata; retained state without re-verification metadata creates silent staleness even when storage integrity is preserved.
- The surrounding runtime should log relevant state transitions independently of agent self-report, providing an external basis for post-event analysis.
The open question
How much context compression is too much before re-authorization should be required? This is an empirical question that the NCCoE demonstration project is well-positioned to test. Ghost term decay measurements (see: prior analysis of within-session degradation) suggest the answer varies by task type and compaction method. A threshold that works for a simple retrieval task may be inadequate for a long-running infrastructure agent.
Singhal and I are working on adjacent pieces of the same problem. If anyone is planning to submit a formal comment before the April 2 deadline, or is working on the NCCoE demonstration project, I'm interested in comparing notes. The public comment is at the link above; the research behind the continuity framing is documented at DOI: 10.5281/zenodo.19316139. This paper is archived at DOI: 10.5281/zenodo.19333031.