Decommissioning and Revocation: Killing an Agent's Authority Cleanly and Provably

Imagine discovering, mid-run, that an agent has been compromised — its credential stolen, or its behavior hijacked. Every design choice that made the agent efficient now works against you: it acts at machine speed, it holds valid credentials, and it may already have delegated authority to sub-agents. Short lifetimes help, because the stolen credential will expire on its own before long. But 'before long' is not 'now', and in the interval the agent remains fully trusted. Closing that interval — ending an agent's authority the moment you decide to, and being able to prove the authority is actually gone — is the job of revocation and decommissioning. This article treats them as first-class operations that must be designed, measured, and verified, rather than as something that expiry quietly takes care of.

Expiry Is Not Revocation

It is tempting to believe that short-lived credentials make revocation unnecessary: if a credential lasts only minutes, why build machinery to kill it early? The answer is that expiry and revocation solve different problems. Expiry is passive and scheduled — a credential dies at a predetermined time regardless of what happens in the world. Revocation is active and event-driven — it invalidates a credential in response to a decision, at a moment you choose, before its scheduled death. The two are complementary: expiry bounds the worst case, and revocation handles the specific case where waiting for the worst-case bound is unacceptable.

The gap between them is precisely the compromise window that remains after you have decided to act. Suppose credentials last ten minutes and you detect a compromise five minutes into one. Expiry alone leaves the attacker five more minutes of full, valid authority. For many actions — exfiltrating data, spending money, corrupting state — five minutes at machine speed is more than enough. Revocation exists to reduce that residual window from 'whatever is left on the clock' to 'the time it takes the revocation to take effect', which a well-built system keeps small and bounded.

So the relationship is not that short lifetimes replace revocation but that they reduce how often it is needed and how much damage precedes it. A system with only expiry has no answer to 'stop this agent now'. A system with only revocation and long lifetimes leans on a control that must always work perfectly. The sound design uses both: short lifetimes as the always-on floor, and revocation as the on-demand override for when the floor is not fast enough.

What It Means to Revoke, Provably

Revocation is the act of causing a credential that has not yet expired to be rejected by verifiers. The word 'provably' matters: a revocation that a controller believes it issued but that verifiers do not actually honor is worse than none, because it creates false confidence. Provable revocation means there is a verifiable property — a check every verifier performs — such that, once the revocation has propagated, no verifier will accept the credential, and this can be confirmed rather than assumed.

This reframes revocation as a property of the verification path, not merely an administrative action. Issuing a revocation instruction is necessary but not sufficient; the instruction only matters when it changes what verifiers do. Accordingly, a revocation has two phases: the decision (a controller determines an identity must lose authority) and the effect (every verifier that could accept the credential now rejects it). The security guarantee lives entirely in the second phase, and the time between the two is the revocation latency — the quantity that determines the residual compromise window.

The zero-trust posture of NIST SP 800-207 makes provable revocation achievable, because it requires every request to be authorized on its own merits rather than trusted by prior context. A system that evaluates each request affords a natural place to consult revocation state; a system that trusts a long-lived session established once has no such checkpoint, which is one more reason the agent identity model rejects the long-lived session in favor of per-request evaluation.

Mechanisms of Revocation

Several mechanisms deliver revocation, and they differ in latency, cost, and completeness. The first is a deny-list: verifiers consult a maintained list of revoked credential identifiers and reject any match. The JSON Web Token format (RFC 7519) gives each token a unique identifier that such a list can name, so a deny-list entry can pinpoint exactly one credential. Deny-lists revoke quickly but require every verifier to consult fresh list state, so their guarantee is only as current as their distribution.

The second mechanism exploits the short-lived design directly: halt renewal. If credentials are short-lived and obtained only by continual re-issuance, then instructing the issuing authority to stop renewing a given identity revokes it within one credential lifetime without touching verifiers at all. This is simple and needs no deny-list, but its latency is the credential lifetime rather than near-zero, so it suits routine decommissioning more than urgent compromise. The third mechanism invalidates the bound key — because credentials are tied to a workload-held key by proof-of-possession, destroying or rotating out that key renders the credential unusable even if presented. The fourth removes the identity from its trust domain entirely, so the naming authority no longer recognizes it; in the SPIFFE model, dropping a workload's registration means the infrastructure will neither renew nor vouch for it.

These are not mutually exclusive; a robust system layers them. For an urgent compromise it deny-lists the active credential for immediate effect and simultaneously halts renewal and drops the registration so the identity cannot return. For a routine teardown, halting renewal and de-registering is enough, and the short lifetime carries the rest.

Propagating a Revocation

For the deny-list mechanism, the security guarantee depends on propagation: the revocation must reach every verifier that could accept the credential before that verifier is next asked to. The flow is a short pipeline. A controller makes the revocation decision and records it in an authoritative revocation store; the store distributes the update to every verifier or to a service verifiers consult; each verifier updates its view; and from then on each verifier rejects the credential. The revocation is fully effective only when the last relevant verifier has the update.

The weak point is any verifier that consults stale state. If a verifier caches an allow decision, or polls the revocation store infrequently, there is a window in which it still accepts a revoked credential. Designing for provable revocation therefore means bounding staleness: verifiers must refresh their revocation view on a schedule tighter than the guarantee you want, or consult authoritative state on each request for the strongest guarantee at the cost of a dependency on that state's availability. This is the classic freshness-versus-availability trade every distributed revocation scheme confronts.

Because propagation latency directly sets the residual compromise window, it should be measured, not hoped for. A system should know its worst-case time from decision to last-verifier-effect and treat that number as the revocation latency it can promise.

Revocation Latency and the Budget

Every revocation scheme has a latency: the time from the decision to the moment the credential is universally rejected. This latency is the single number that characterizes how well a system can 'stop an agent now', and it deserves an explicit budget. A team should decide, from the sensitivity of what its agents can do, the maximum residual window it will tolerate — the revocation latency budget — and then choose mechanisms and refresh cadences that meet it.

The budget makes the design choices concrete. If the tolerated window is a fraction of a second, only per-request consultation of authoritative revocation state or immediate key invalidation will do, and the system must accept a hard dependency on that state's availability. If the tolerated window is a minute or two, a tight refresh of distributed deny-lists suffices, and if it is a full credential lifetime, simply halting renewal meets the budget with no verifier-side machinery at all. There is no single right answer; there is only a budget chosen from impact and a design that provably meets it.

Framing latency as a budget also guards against a common failure: assuming revocation is instantaneous. It never is. Naming the number forces the system to confront its real residual window and to size the rest of its controls — monitoring, containment, blast-radius limits — around the authority an agent still holds during that window.

Decommissioning the Whole Agent

Revoking a single credential is not the same as decommissioning an agent. An agent that has run for a while has a footprint: the identity itself, the current credential, any credentials it obtained through renewal, and — critically — the delegated credentials it minted for sub-agents through token exchange. Decommissioning means ending all of it, provably, so that no fragment of the agent's authority survives its retirement.

The delegated children are the part most easily missed. Because a planning agent can hand narrowed, attributed credentials to sub-agents, revoking only the planner's own credential can leave those children valid and acting. Provable decommissioning therefore has to walk the delegation tree the agent rooted and revoke or expire every branch, or rely on a design in which children's authority is derived from and cannot outlive the parent's — for instance by binding child credential validity to the parent's continued good standing. Either way, the requirement is that decommissioning the root leaves no delegated authority behind.

Decommissioning also has a routine, non-incident form: the ordinary retirement of an agent that has finished its work. The same completeness applies, just without urgency. A clean teardown de-registers the identity so it cannot be renewed, lets or forces its credentials to lapse, and accounts for its delegated children — turning 'the agent is gone' from a hopeful statement into a verifiable one. This completeness is what lets fleet-level governance trust its own inventory, because a decommissioned agent that leaves live credentials behind is an identity the inventory thinks is gone but that can still act.

Choosing a Strategy

The right revocation strategy depends on two factors: how urgent the action is, and how reversible the agent's effects are. Urgency separates a suspected active compromise, where the residual window must be near-zero, from a routine retirement, where one credential lifetime is fine. Reversibility separates agents whose actions can be undone, where a slightly larger window is tolerable because damage can be repaired, from agents that can take irreversible steps — moving money, sending communications, deleting data — where even a small window demands the fastest available mechanism.

Crossing these two factors yields a simple map. An urgent compromise of an agent with irreversible effects calls for the strongest, lowest-latency response: immediate key invalidation or per-request revocation consultation, plus de-registration, plus walking the delegation tree. A routine retirement of a reversible-effect agent needs only halted renewal and de-registration. The off-diagonal cases — urgent but reversible, or non-urgent but irreversible — sit in between and guide how much latency and machinery are warranted. The value of the map is that it turns 'how should we revoke this' into a decision driven by impact rather than habit.

Limitations and Threats to Validity

This treatment is an architectural synthesis grounded in established identity standards, and its guarantees are conditional. Provable revocation assumes verifiers actually consult revocation state within the promised freshness; a single verifier that caches decisions or falls back to accepting on error silently reopens the window, so 'every verifier' is a strong requirement that must be enforced and audited, not presumed. The delegation-tree completeness of decommissioning assumes the tree is discoverable or that child validity is derived from the parent; if delegated credentials can be minted without a traceable link to their root, walking the tree is impossible and only expiry will eventually clean them up.

Two residual risks bound the achievable guarantee. First, revocation latency is never zero, so there is always some window in which an agent under revocation still holds authority; the honest posture is to measure that window and size containment around it rather than to claim instantaneous revocation. Second, revocation ends an authority but does not undo what was already done with it — a credential revoked one second too late has still authorized whatever it authorized in that second, which is why revocation must be paired with blast-radius limits and, for irreversible actions, with controls that prevent the action during suspected compromise rather than merely revoking afterward. Revocation cleanly ends authority; it does not rewind consequences.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

on_revoke(identity, ctx):
  actions = ["halt_renewal", "de_register"]      # always
  if ctx.urgent:                                   # suspected compromise
    actions += ["deny_list_active_cred"]
  if ctx.effects == "irreversible":
    actions += ["invalidate_bound_key"]            # immediate
  if identity.has_delegations:
    actions += ["walk_delegation_tree_and_revoke"] # no orphaned children
  assert verifier_freshness <= latency_budget      # provable within budget
  return actions

Glossary

Revocation

Causing a credential that has not yet expired to be rejected by verifiers, in response to a decision and before its scheduled expiry.

Provable revocation

Revocation backed by a verifiable property so that, once propagated, no verifier will accept the credential, and this can be confirmed rather than assumed.

Revocation latency

The time from the decision to revoke to the moment the credential is universally rejected; it sets the residual compromise window.

Deny-list

A maintained list of revoked credential identifiers that verifiers consult, rejecting any credential whose identifier matches.

Halt renewal

Revoking a short-lived identity by instructing the authority to stop re-issuing it, so it lapses within one credential lifetime.

De-registration

Removing an identity from its trust domain so the naming authority no longer renews or vouches for it.

Decommissioning

Ending an agent's entire identity footprint — the identity, its credentials, and its delegated child credentials — so no authority survives retirement.

Revocation latency budget

The maximum residual window a team will tolerate, chosen from impact, which the revocation design must provably meet.

References

1. IETF RFC 7519, JSON Web Token (JWT)
2. IETF RFC 6749, The OAuth 2.0 Authorization Framework
3. IETF RFC 8693, OAuth 2.0 Token Exchange
4. SPIFFE — Secure Production Identity Framework For Everyone, specification (CNCF)
5. NIST SP 800-207, Zero Trust Architecture (2020)
6. NIST SP 800-63-3, Digital Identity Guidelines (2017)
7. OWASP Agentic Security Initiative, Agentic AI Threats and Mitigations (2025)
8. NIST AI 100-1, AI Risk Management Framework (AI RMF 1.0)