By HumanAudit Inc. editorial teamLast reviewed 5 August 2026
VerifiedLast reviewed 5 August 2026 by the HumanAudit Inc. editorial team.Corrections logEditorial policy
On this page
  1. Why expiry is not revocation
  2. Four layers of a kill path
  3. Measuring your real revocation time
  4. Running the drill
  5. Designing for revocability
  6. FAQ

TL;DR

  • Design the kill path before the grant path. Most deployments have a specified provisioning flow and an untested revocation flow.
  • Expiry bounds exposure by time. Agents act fast enough that time is the wrong unit: actions taken is the relevant measure.
  • A working kill path has four layers: credential invalidation, push-based signal, enforcement-point reaction, and execution halt. Most organisations have the first only.
  • The number that matters is measured time from revocation instruction to confirmed loss of access. If you have not measured it, you do not know it.
  • Run the drill quarterly. A designed control that has never been exercised is an assertion.

Why expiry is not revocation for agents

Short credential lifetimes are the right default and they solve a real problem: a stolen credential becomes useless on its own. They do not solve revocation, and the gap widens specifically for agents.

Consider a compromised credential with a fifteen-minute remaining lifetime. Held by a human, the attacker performs perhaps a few dozen operations at human interaction speed. Held by an agent with tool access, the same window permits thousands of operations at machine speed, including operations the agent was legitimately capable of but should not have been directed to perform.

The unit of exposure is actions, not minutes. This is why the Shared Signals Framework and CAEP exist, and why push-based revocation stops being an advanced capability and becomes a baseline one once agents hold consequential permissions.

The question to ask your team today

"If we decide right now that an agent must stop, how long until it cannot act, and how do we know?" The common answer is a description of a process rather than a number. A described process that has never been exercised has an unknown execution time, and unknown is not a risk position you can report.

The four layers of a working kill path

  1. Credential invalidation. The credential is marked invalid at the issuer, and no new credentials are minted for that identity. Necessary, and on its own the weakest layer, because credentials already in flight remain valid until something checks.
  2. Push-based signal. The revocation decision is pushed to enforcement points rather than waiting for them to re-validate. This is what the Shared Signals Framework and CAEP standardise. Without it, your revocation latency equals your token lifetime regardless of how fast the decision was made.
  3. Enforcement-point reaction. The receiving systems must actually act on the signal, terminating in-flight sessions rather than merely declining the next authorisation. A gateway that honours a signal only at the next token refresh has not implemented revocation.
  4. Execution halt. The agent's own runtime stops. An agent mid-plan with cached context and queued tool calls may continue attempting work after its credentials are gone, generating errors, retries and side effects. Stopping the workload is a distinct action from revoking its identity, and it is the layer most often missing entirely.

Most organisations we assess have layer one, partial layer three, and neither two nor four.

Measuring your real revocation time

The measurement is straightforward and almost nobody has run it:

  1. Pick a non-production agent with representative permissions.
  2. Have it perform a repeating, observable, harmless action against a real downstream system.
  3. Issue a revocation through your normal process, not a shortcut. Record the timestamp.
  4. Record the timestamp of the last successful action.
  5. The difference is your revocation time. Record what the delay consisted of.

Typical first results run from several minutes to several hours, and the dominant component is usually not the decision but the propagation: enforcement points that only re-check at token refresh. That decomposition is what makes the number actionable.

Record the figure. It belongs in your ISO/IEC 42001 clause 10 evidence, in your board reporting, and in any incident response plan that claims agents can be contained.

Running the drill

  • Quarterly, and after any change to issuance or gateway configuration. Both routinely break the path silently.
  • Use the normal process. A drill that uses an engineer with console access measures that engineer, not the control.
  • Include the out-of-hours case. Revocation at 03:00 on a Sunday is the scenario that matters, and it is usually much slower.
  • Test partial revocation. Removing one permission is a more common real need than killing an agent outright, and it is frequently unsupported.
  • Record the result whether or not it is good. A recorded four hours is a fundable problem. An unrecorded assumption of "immediate" is a future incident report.

Designing for revocability

  • Externalise authorization. If permission is evaluated at each call against a policy decision point, revocation is a policy change taking effect at the next call rather than a credential lifecycle event. This is the single highest-leverage design choice, and it is why AuthZEN's scope discipline matters.
  • Prefer per-invocation credentials over standing ones. Authority that must be re-obtained is authority that can be withheld.
  • Make the agent's runtime addressable. You must be able to stop the process, not only invalidate its identity.
  • Instrument the path. Alert when a revocation signal is emitted but not acknowledged by an enforcement point. Silent failure here is the norm.
  • Bound the blast radius so revocation matters less. An agent scoped narrowly enough is one whose revocation latency is tolerable. Scope reduction and revocation speed substitute for each other.

Frequently asked questions

Is token expiry the same as revocation?

No. Expiry bounds how long a credential remains usable; revocation is a decision to stop an identity now. The gap matters more for agents than for humans because the unit of exposure is actions rather than minutes: a fifteen-minute window permits a human a few dozen operations and an agent thousands. Short lifetimes are the right default and are not a substitute for a working kill path.

How do you measure agent revocation time?

Take a non-production agent with representative permissions, have it perform a repeating observable action against a real downstream system, issue a revocation through your normal process and record the timestamp, then record the timestamp of the last successful action. The difference is your revocation time. Decompose the delay, because the dominant component is usually propagation to enforcement points rather than the decision itself.

What are the four layers of an agent kill path?

Credential invalidation at the issuer; a push-based signal to enforcement points, which is what the Shared Signals Framework and CAEP standardise; enforcement points actually terminating in-flight sessions rather than declining the next authorisation; and halting the agent's own runtime, since an agent mid-plan with cached context and queued tool calls may keep attempting work after its credentials are gone. Most organisations have the first and part of the third.

Why do agents keep acting after their credentials are revoked?

Because stopping a workload is a different action from invalidating its identity. An agent holds cached context, an in-progress plan and often queued tool calls. Revoking credentials causes those calls to fail, which produces errors, retries and sometimes side effects, but does not stop the agent attempting them. The execution-halt layer is the one most often missing entirely.

What is the highest-leverage design change for revocability?

Externalising authorization to a policy decision point evaluated at each call. When permission is decided per call rather than baked into an issued credential, revocation becomes a policy change effective at the next call rather than a credential lifecycle event with propagation delay. Narrow scoping is the complementary move: an agent bounded tightly enough is one whose revocation latency you can tolerate.

Have you measured your revocation time?

Almost nobody has, and the number is usually much larger than assumed. HumanAudit runs revocation drills against real environments and produces the measured figure plus the remediation path.