Governing Autonomous Systems: Auditability, Non-Repudiation, and Revocation
Part of the series The Authentication and Authorization Challenges of Agentic AI.
Every previous post in this series has been about getting something right in the moment: establishing who the agent is, proving delegation, getting meaningful consent, mediating trust across domains, authorizing tool calls, scoping data access. This last one is about what happens afterward. Even a system that gets all six of those right, all the time, still needs to answer three questions when something goes wrong, or when someone simply asks: what happened, can we prove what was actually authorized, and can we stop it right now. That’s the governance gap, and it’s the one that determines whether everything else in this series produces a system you can actually stand behind six months from now.
Logging is not the same thing as governance
Most systems log that an API call succeeded or failed. That’s necessary and almost never sufficient. The question that actually gets asked after an incident is rarely “did this call succeed” — it’s “why was this call allowed to succeed,” and answering that requires the decision chain, not just the outcome: which agent identity presented the request, acting for which user, under which specific delegation, approved through which specific consent (if any), evaluated against which relationship facts (if the action involved retrieving or modifying scoped data). If that chain isn’t captured at the time the decision is made, it can’t be reconstructed afterward from the outcome alone, no matter how detailed the outcome log is.
This is where the earlier posts in this series pay off directly, rather than being independent concerns. A distinct agent identity (the identity gap) is what makes “which agent” answerable at all. The nested actor claims from token exchange (the delegation gap) are what make “acting for which user, through how many hops” reconstructable rather than collapsed into a single flattened identity. The structured authorization payload from asynchronous consent (the consent gap) is what turns “the user approved this” into “the user approved this specific, described action” — the difference between a real audit trail and an assertion nobody can verify.
Non-repudiation: proving intent, not just asserting it
Non-repudiation means being able to demonstrate, after the fact, that a specific party authorized a specific action — not merely that a broad grant existed somewhere that could have covered it. This is precisely where a generic scope grant and a Rich Authorization Requests payload diverge in practical value. “The user approved billing access” doesn’t tell you whether they approved this specific refund. “The user approved a $2,000 refund to order #12345, and here’s the signed structured request they approved” does. The second is evidence in a meaningful sense; the first is closer to a plausible excuse.
The same logic extends to the agent’s own actions. If an agent executed something different from what was actually approved — a different amount, a different recipient, a broader action than the one described in the consent request — that drift is only detectable if both the approved payload and the executed action are recorded in comparable, structured form. A system that only logs “approved: yes” and “action taken: refund processed” has no way to notice that those two things didn’t actually match.
Revocation as a real-time operation, not an eventual one
The other half of governance is being able to stop something immediately, and have that action actually take effect immediately — not “eventually, once the token expires” or “once we rotate the shared secret and break every other agent using it too.”
This is where the earlier design choices in this series compound into something that either works cleanly or doesn’t. If agent identities are distinct per instance (rather than shared across a fleet), and tokens are short-lived, narrowly scoped, and re-exchanged frequently (rather than long-lived and broadly scoped), then revoking one specific agent’s access — or one specific delegation chain, or one specific grant — is a targeted, collateral-free operation. If those earlier choices were skipped in favor of convenience, revocation becomes a blunt instrument: rotating a shared secret that several unrelated agents depend on, or waiting out the remaining lifetime of a token that was scoped far more broadly than the moment called for.
Two protocol-level pieces make real-time revocation actually operational rather than theoretical: token introspection (RFC 7662), which lets a resource server check, at the moment of use, whether a presented token is still valid rather than trusting it blindly until its stated expiry; and token revocation (RFC 7009), which gives an authorization server a standard mechanism to invalidate a token on demand, ahead of its natural expiry. Together, these are what turn “we revoked the agent’s access” from a statement about the next time a long-lived token happens to expire into a statement about right now.
This is also the strongest practical argument, elsewhere in this series, for short-lived, frequently re-exchanged tokens over long-lived ones: a token that expires in minutes and gets re-requested for each task is a token where a revocation decision takes effect almost immediately by construction, without needing every resource server to perform an introspection call on every single request. Long-lived tokens push more of the revocation burden onto real-time introspection infrastructure; short-lived ones push less.
Design guidance
Capture the decision chain at the moment it’s made, not just the outcome. Every consequential action should have a recoverable answer to: which agent, acting for which user, under what delegation, approved under what specific authorization payload (if consent was required), evaluated against which access-control facts (if data access was involved). If any link in that chain only exists in application memory during the request and isn’t persisted, it’s unrecoverable the moment someone actually needs it.
Treat structured, specific authorization payloads as audit artifacts, not just UX niceties. The value of Rich Authorization Requests isn’t only a better approval prompt — it’s a machine-comparable record of exactly what was approved, which is what makes drift between approval and execution detectable at all.
Build revocation granularity in before you need it, not while you need it. The right test is a specific, concrete question: if one agent instance needs to be shut off right now, today, can that happen without affecting any other agent, any other user, or requiring a shared secret rotation? If the honest answer involves “we’d need to rotate something that several things depend on,” that’s a gap worth closing before an incident forces the question.
Periodically test whether your recorded data can actually answer a real question. Pick a plausible past scenario — an agent took an action, someone asks why — and try to answer it using only what your systems actually recorded, not institutional memory of how things are supposed to work. If the honest answer is “we’d have to guess” or “we’d have to ask the engineer who built it,” the audit trail is decorative.
Treat governance as a design input from day one, not a system bolted on after the first incident. Every choice made in the earlier posts in this series — a distinct agent identity, narrowly scoped and re-exchanged tokens, structured consent payloads, relationship-level access checks — either supports real governance directly or makes it materially harder to retrofit later. Governance isn’t a separate eighth system sitting alongside identity, delegation, consent, trust, tool authorization, and data scoping; it’s the property that emerges when those six are each done with the afterward question already in mind.
Closing the series
None of the seven gaps this series has covered required inventing a new discipline. Least privilege, explicit and provable delegation, meaningful consent, mediated trust, properly authenticated tool access, instance-level data authorization, and the ability to prove what happened afterward — these are the same properties identity and access management has always aimed for. What’s different is the shape of the system they now have to hold together: a principal that reasons about what to do next, chains through other services and other agents, and sometimes acts with nobody watching in real time. The protocols mostly already exist to support that shape. The work is recognizing, deliberately, everywhere the old assumptions quietly stop holding — and building for the actor that’s actually there, not the human or the static machine client it superficially resembles.