Revocation is the control you test, not the one you assume
Almost every agent platform has a disable button. Far fewer can say how long it takes to be effective, which credentials it does not cover, or what happens if the service that stores the switch is unreachable at the moment it is pressed. Those three answers are the control; the button is the interface to it.
Treat revocation as a drill. Revoke a real agent in a real environment, then try to use it, and record the interval between the two. The number you get is the real containment window, and it is the only version of it that anyone should quote in an incident review.
If nobody has measured how long revocation takes to bite, the honest answer to “how fast can you stop it?” is that you do not know.
Short lifetimes and revocation solve different halves
A short-lived token bounds the damage of a credential that leaks without anyone noticing: it stops working on its own. It does nothing for the case where you have noticed, because you are not willing to wait out its remaining lifetime while an agent misbehaves.
Revocation is the opposite. It acts immediately on the credentials you know about, and does nothing about the ones you do not. A design that relies only on expiry cannot respond; a design that relies only on revocation cannot contain what it never detected. Production agents need both, and the token lifetime is what sets the worst case when detection fails.
Layer the switches, and make each layer independently sufficient
One switch is a single point of failure for the exact moment you most need it to work. A workable arrangement has several, each of which can stop traffic on its own: an individual credential can be revoked, an individual agent suspended, a whole tenant halted, and the platform stopped for everyone.
The per-tenant layer is the one most often missing, and it is the one an incident actually calls for — stopping one customer's fleet without stopping everyone else's. A global switch that is the only real option gets used late, because using it is an outage.
- Per credential: the narrowest action, and the right one for a suspected leak.
- Per agent: stops one deployment without touching its siblings.
- Per tenant: contains a customer-scoped incident. Frequently missing.
- Platform-wide: the last resort, and it should be genuinely last.
Choose the failure direction per layer, on purpose
When the store holding a kill switch cannot be read, the system must still decide. Failing closed refuses every call and converts a cache outage into a full outage. Failing open keeps serving and accepts a window in which a revocation is not honoured. Neither answer is right in general, and homogenising them across a system is how the reasoning gets lost.
Reason about each control separately. A revocation check that has an independent backstop can reasonably fail open, because a second layer still catches the revoked agent. A pre-authentication credential lookup should fail closed, because an unreadable credential was never authenticated in the first place, and serving it would be authenticating nothing. Whichever way each one goes, write down why — an undocumented direction gets flipped during the next outage by someone optimising for availability.
Rotation is not revocation, and neither is deletion
Rotation issues a new credential. Whether the old one stops working is a separate decision, and overlap windows exist precisely so it does not — which means a rotated credential can remain valid for exactly as long as an attacker needs. Rotation without an explicit revocation of the previous value is a change of key, not a containment step.
Deleting a record is also not revocation if anything caches it. A credential that survives in a positive-result cache, in a session, or in a token that was already minted is still usable, so the revocation path has to reach every layer that can answer yes. This is the reason to be sceptical of caching authorization results at all, and to keep any such cache short and explicitly invalidated.
Prove the revocation, to people who cannot see your dashboard
After an incident, the questions come from outside: when did it stop, was the credential used after that, and how do we know. Answering from an internal dashboard asks the questioner to trust the system under review. A signed, timestamped record of the revocation and of the calls around it can be checked independently.
The public form of this is a signed revocation list a counterparty can fetch, so they can establish whether an identity was still valid at a given time without asking. Publish it carefully: expiry and rotation are safe to state publicly, while an emergency suspension broadcasts that an incident is underway. The distinction is worth designing before it is needed.
Frequently asked questions
Short answers to the questions that matter.
How fast should revocation take effect?
Fast enough that you are willing to say the number out loud. In practice that means the switch is read on the request path rather than refreshed on a schedule, and any cache in front of it is measured in seconds. Whatever the design, the figure to quote is the one from a drill, not the one from the architecture diagram.
Does revoking an agent invalidate tokens it has already been issued?
Only if something on the request path checks revocation state on every call. A signed token is valid by construction until it expires, so a system that verifies the signature and nothing else will keep honouring it. This is why short lifetimes and an on-path revocation check are complementary rather than alternatives.
Should revocation checks fail open or fail closed?
It depends on whether another layer catches the same failure. A check with an independent backstop can fail open so that a cache outage is not a full outage; a pre-authentication lookup with nothing behind it should fail closed, because an unreadable credential was never authenticated. Decide per control and document the reason.
Is publishing a revocation list safe?
Partly, and the split matters. Expiry and rotation are routine lifecycle facts and are safe to publish. An emergency suspension is incident state, and publishing it tells everyone — including whoever caused it — that you are responding. A public list should carry the first and withhold the second.
Primary sources