Earlier this summer I argued that your agents need identities, not API keys. I still think that is the right first move, and I now think it is roughly a third of the problem.
Three independent efforts, from three very different institutions, published within seven months of each other, all landed on the same second requirement. Not “who is this agent” — that is identity, and it is comparatively tractable. Not even “may it do this” — that is authorization, and we have decades of policy machinery for it.
The requirement they converged on is: can you prove, afterwards, what it did and who authorized it?
That is non-repudiation, and it is an infrastructure problem that lands squarely on platform teams.
Three signals, one requirement
NIST names the properties
On 5 February 2026 the NIST National Cybersecurity Center of Excellence published a concept paper, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, with a comment period that closed on 2 April 2026.
The properties it solicits feedback on are worth listing exactly, because the ordering is instructive:
- Identification of AI agents
- Authorization controls for agent access
- Auditing
- Non-repudiation
- Controls to prevent and mitigate prompt injection
Items three and four are the ones most agent platforms cannot currently satisfy. Most teams have some version of one and two — a service account, a scoped token, an allowlist. Almost none have an artifact that would survive being challenged.
A Senate bill makes it an obligation
S.5051, the AI AGENT Act of 2026, was introduced by Senator Mark Warner on 21 July 2026 and referred to the Committee on Commerce, Science, and Transportation. It follows a discussion draft released in late June.
Two provisions matter here. The bill defines a “custodial user agent” as one authorized to act for a user in a transparent, documented, limited and revocable manner, and requires such agents to maintain real-time auditable records of the actions they take. And it directs NIST to identify existing open protocols — or develop standards where none exist — for verifiable, scope-limited consent delegation and revocation, along with auditable verification of the actions an agent takes.
I want to be careful about how much weight this carries. It is an early-stage bill in a Congress that passes very few of them, its obligations attach to large consumer platforms rather than to internal enterprise systems, and it will change substantially if it moves at all. Do not build to this bill. Build because of what it indicates: when a regulator reaches for agent governance, the first thing it reaches for is the record.
MCP puts it in the protocol
The MCP roadmap published 22 August 2026 — which I covered in more detail in what to build for the next MCP release — names agent identity as a priority area, with this diagnosis:
More and more of the callers are agents running as cloud workloads with their own identity, acting on behalf of a user who isn’t present.
Its commitments are Demonstrating Proof of Possession and an opinionated path for delegation through Workload Identity Federation. DPoP is a non-repudiation primitive in disguise: binding a token to a held key means an action taken with that token can be attributed to the holder rather than to whoever happened to obtain a copy.
Three efforts, three constituencies — standards body, legislature, protocol project — converging on the same clause: acting on behalf of a user who is not present.
Why identity alone does not get you there
Suppose you have done the identity work properly. Every agent has a distinct workload identity, short-lived credentials, scoped permissions. Good. That is genuinely most of the security benefit.
Now an action goes wrong. A customer’s data was deleted, a payment went out, a production config changed. The question arrives, and it is never “which agent” — your logs answer that. It is:
“Who authorized this?”
Walk through what you would need to answer it defensibly:
- Which agent instance took the action — not which service, which run, since a fleet of identical agents shares a service identity
- Which principal it was acting for
- Which grant authorized that — its scope, when it was issued, when it expired, whether it had been revoked at the moment of the action
- What the agent actually did, at what granularity, with what parameters
- Whether that action fell inside the grant’s scope
- All of it recorded in a way that could not have been written afterwards
Most agent platforms can produce the first item and a rough version of the fourth. The grant reference — item three — is the one that carries the entire evidentiary weight, and it is the one almost nobody records, because at the time of the action it feels redundant. The system already checked the permission. Why write down that it checked?
Because “the system checked” is not evidence. It is a claim about code that has since been deployed over.
This is the same failure mode I wrote about in postmortems for agent-caused incidents: the investigation stalls not because nobody logged anything, but because what was logged answers a different question than the one being asked.
Your traces are not an audit trail
This is the part I most want to land, because it is where I see well-run teams make a reasonable-sounding mistake.
If you have instrumented your agents with OpenTelemetry GenAI conventions, you have detailed records of agent behavior — spans for the loop, tool calls, model requests, token counts. It is natural to conclude the audit problem is solved.
It is not, and the reasons are structural rather than a matter of adding attributes:
| Property | Reasoning trace | Authorization record |
|---|---|---|
| Completeness | Sampled — often aggressively | Must be complete |
| Retention | Days to weeks, set by cost | Months to years, set by policy |
| Mutability | Freely dropped, reprocessed, downsampled | Append-only, tamper-evident |
| Content | Prompts, reasoning, intermediate steps | Grant, scope, decision, action |
| Sensitivity | Often contains raw prompt content | Should contain no prompt content |
| Consumer | An engineer debugging on Tuesday | An auditor, a regulator, opposing counsel |
That last row is the whole argument. These artifacts have different readers with different questions and different standards of proof.
The content difference cuts both ways, and it is worth dwelling on. A reasoning trace containing full prompts and tool outputs is a liability if you retain it for seven years — it is a lake of customer data with a long retention policy. An authorization record should be deliberately thin: identifiers, scopes, decisions, timestamps. No prompt text. That thinness is what lets you retain it for as long as you need to without accumulating risk.
Emit both, from the same code path, into different stores, with different retention. They correlate through a shared ID. They are not the same artifact, and building one while believing you have built the other is how teams discover the gap during an audit rather than before one.
What to build now
The standards will keep moving. The facts they need recorded will not, because they follow from the structure of delegation rather than from anyone’s design choices. So capture the facts in your own schema and map them later.
1. Make grants first-class objects. A delegation grant should be a stored record with an ID, a principal, an agent identity, an explicit scope, an issue time, an expiry, and a revocation state. If your authorization is “the agent has a token with these scopes baked in,” you have permissions but no grant, and nothing to reference in an audit record.
2. Reference the grant in every action record. Not the permission that was checked — the ID of the grant that authorized it, resolvable to the scope as it stood at that moment. This is the field that turns a log line into evidence.
3. Bind agent instance, not just service. A fleet of identical agents sharing one service identity cannot answer “which run did this.” Instance identity, correlated to the session and the grant.
4. Record the decision, not just the outcome. “Allowed, by policy X version 7, against grant G, scope S.” When the policy changes — and it will — you need the version that was in force.
5. Keep records thin and separate. Identifiers and decisions in the audit store. Prompts and reasoning in the trace store. Correlated by ID, retained on different schedules, with different access controls.
6. Make the store append-only. Non-repudiation requires that the record could not have been written after the fact. Append-only storage with hash chaining is the low-effort version; it is dramatically better than a table someone with production access can UPDATE.
7. Test it with a real question. Pick an action from three weeks ago and try to answer, end to end, who authorized it and whether it was in scope. If that takes more than a few minutes, or bottoms out in “well, the policy at the time probably said…”, you have found the gap while it is still cheap.
That last one is the only item on the list I would call urgent, because it is the only one that tells you which of the other six you actually need.
The shape of the next two years
We spent 2026 arguing about whether agents should have their own identities. That argument is over; they should, and the tooling is arriving.
The next argument is about evidence — and it is a harder one, because evidence has to be produced at the time of the action by systems that were designed before anyone asked for it. You can retrofit an identity onto a running agent in an afternoon. You cannot retrofit a record of what it did last March.
Every one of the three signals above is a request for the same artifact, phrased in the vocabulary of a different institution. NIST calls it non-repudiation. The bill calls it real-time auditable records. MCP calls it proof of possession and delegation. It is one thing: a durable, thin, tamper-evident record binding an action to a grant.
It is not glamorous work. It is a schema, a store, and a discipline about what goes where. But it is the difference between an agent incident that ends in a postmortem and one that ends somewhere considerably more expensive.
Related
- Your agents need identities, not API keys — the first third of the problem
- MCP’s next release deletes your polling loop — DPoP and Workload Identity Federation in the protocol
- Postmortems for agent-caused incidents — what the missing record costs you during an investigation
- Tracing the agent loop with OTel GenAI conventions — the artifact this one is not
- The OWASP Agentic Top 10 for platform teams — the threat model these controls sit inside
- Bounded autonomy for AI SRE agents — scoping the grants in the first place
Sources: NIST NCCoE concept paper, Accelerating the Adoption of Software and Artificial Intelligence Agent Identity and Authorization, 5 February 2026 · S.5051, AI AGENT Act of 2026, Congress.gov · Davis Wright Tremaine analysis of the AI AGENT Act · The New MCP Roadmap, 22 August 2026
Comments