I need to correct something I wrote in a design document in June.

I had specified that credentials issued to agents expire after fifteen minutes. I wrote it without thinking about it, the way everybody writes token lifetimes: fifteen felt short enough to be responsible and long enough not to cause operational pain. It sat in the document for weeks looking like a security control.

A reviewer asked what the fifteen was for.

Not "is fifteen right." What is it for. What property does the number provide, and what would go wrong at fourteen or sixteen.

I did not have an answer. I had a habit.

The honest answer, which took me an uncomfortable afternoon to arrive at, is that a fifteen-minute time-to-live provides exactly one property: an upper bound on how long a credential remains usable after you have decided it should not be. It is not a limit on damage. It is not a containment mechanism. It is a promise that the window of unauthorised action will close on its own, eventually, without anybody doing anything.

Stated that way, the number changes character completely. Fifteen minutes is not a cautious choice. It is a decision to permit fifteen minutes of action after the moment you decided to stop.

In a software estate that window costs you a restore and an apology. Where the effect is physical, fifteen minutes is measured in what moved.

What a TTL actually is

Let me be precise, because there is a version of this argument that overreaches and I want to stay inside the defensible version.

A time-to-live does real work. It bounds the value of a stolen credential. It forces a re-authentication cycle that can pick up changed policy. It limits the blast radius of a leaked token in a way that requires no coordination between systems, which is why it became universal — it works when nothing else is working, and that is a genuinely valuable property in distributed systems.

What it does not do is stop anything on demand.

The mental model most teams carry is that revocation and expiry are two routes to the same place. They are not. Expiry is a passive property of a credential: it becomes invalid at a time fixed when it was issued. Revocation is an active property of a system: something has to happen, propagate, and be checked.

When people say "we can revoke agent credentials," what is usually true is one of three much weaker statements. We can stop issuing new ones. We can revoke them and the revocation will be picked up at the next refresh, which is up to a TTL away. Or: we have a revocation list, and the check against it fails open when it cannot be reached.

That third one is the most common and the least discussed, and it is worth sitting with. A revocation check that fails open converts your revocation capability into a request.

Why agent speed breaks the model

Here is the part that is genuinely different about autonomous systems, rather than being an old problem with new vocabulary.

A time-to-live is a bet that the number of consequential actions taken in the window is small. That bet was reasonable when the entity holding the credential was a human, or a service doing a bounded amount of scheduled work. A person with a fifteen-minute window does a handful of things.

An agent with a fifteen-minute window does as many things as the system will accept. If the action rate is one per second, the window is nine hundred actions. If the workflow fans out, it is more. The window is not fifteen minutes of risk; it is fifteen minutes multiplied by a throughput that was designed to be high.

That is the sense in which a time-to-live is formally inadequate at agent speed. The quantity a TTL bounds — elapsed time — has become nearly uncorrelated with the quantity you care about, which is consequential actions taken after the decision to stop.

What replaces it

Two things, and they are complementary rather than alternative.

Bound revocation by execution count and release consistency, not only by time. A credential carries a budget of consequential actions as well as a lifetime, and the budget is checked at the point of use rather than at the point of issue. A revocation decision then has a bounded cost in actions, which is the unit that actually matters, rather than in seconds, which is a proxy that has stopped tracking.

State the revocation latency as a number, and treat it as an engineering budget. This is the part I would push hardest, because it is the part that changes conversations.

The design I have been working on carries a performance budget table, and the interesting rows are not the throughput ones. They are:

  • identity revocation propagates to all replicas in under 5 seconds
  • credential revocation in under 1 second
  • the kill path reaches a defined safe state end to end in under 5 seconds
  • the egress mediation layer costs under 2% of throughput

Read those as an operator rather than an engineer. The first three are not performance targets. They are governance properties expressed as latencies. "Under one second" is a statement about how much unauthorised action is possible after a decision, in the only unit that a plant manager or a regulator will find meaningful.

And the fourth row is doing quiet, essential work. An enforcement layer that costs twenty percent of throughput will be switched off, and it will be switched off during the incident, by someone under pressure who needs capacity. A control's overhead budget is part of its security specification, because a control that is disabled when things get difficult is not a control. Writing "under 2%" into the specification is what makes the first three rows survivable in production.

The number nobody publishes

Here is a claim I would like to be wrong about, and I have looked reasonably hard.

No open-source project in this space publishes a revocation service-level agreement.

Identity systems document how to revoke. Policy engines document how to change a decision. Credential brokers document lifetimes. What none of them state, as a number they hold themselves to, is: from the moment revocation is requested, what is the maximum time before the credential cannot be used anywhere in a deployment of size N.

That number is hard, which is why nobody publishes it. It depends on replica count, network topology, cache behaviour, and what happens when a check fails. But the difficulty is the argument for stating it, not against. An unstated latency is not zero. It is unbounded, and in most deployments it is silently equal to the TTL, which brings us back to the fifteen minutes nobody could justify.

So the question worth asking a vendor is not "can you revoke." Everyone can revoke. It is: what is your revocation latency, in seconds, at my deployment size, and what happens to that number when the revocation service is unreachable?

I have asked versions of that question and the responses sort cleanly into three groups: an actual number with conditions attached, which is rare and impressive; a description of the mechanism, which is an answer to a different question; and a pause.

Where this stops being a software argument

Everything above holds in a purely digital estate. Where the effect is physical, three things change, and they change in the same direction.

The window is not measured in time. It is measured in what completed. Material fed, a hole drilled, a valve cycled, a dose delivered, a vehicle moved. A revocation that lands after the actuator has moved has not prevented anything; it has documented something.

The rollback does not exist. In software, the residue of a late stop is usually recoverable — restore, replay, reconcile. A physical effect that has occurred is a new initial condition. Every agent-safety control in wide circulation was designed by people whose worst case was a bad database write, and the assumption travels with the control into environments where it does not hold.

The safe state is not "stopped." This is the one that is most often got wrong. For many physical processes, cutting power is not the safe state — it is a different hazard. A safe state is a defined configuration that has to be specified per process, and reaching it takes a bounded, non-zero time that has nothing to do with the speed of your software.

Which produces a rule I would put in any specification touching physical systems: the kill path's latency budget and the process's time-to-safe-state are two different numbers, and the second one is not yours to set. Your budget is how fast you can begin. The process decides how fast it can arrive.

The instrument, and the gap inside it

One piece of legislation is worth naming here, and one thing about it is more interesting than the rest.

The AI Kill Switch Act, introduced on 23 July 2026, mandates four capabilities and attaches penalties reaching twenty million dollars per day for defying a shutdown order. That is a serious instrument with a serious number attached.

The interesting part is what it does not contain. The verification format is unspecified. The bill mandates capabilities. It does not define how an operator demonstrates possessing them, what evidence satisfies a verifier, or what a conformance report looks like.

I want to be careful about the status here: this is introduced legislation, not law, and I am not going to characterise it as binding anybody today. What makes it relevant regardless is the shape it reveals. A capability has been named as mandatory before any test for it exists. That is the same shape as the model-risk guidance that placed agentic systems out of scope and promised a specification later, and the same shape as the supervisory frameworks that require monitoring without defining what a monitoring record must contain.

In every case the demand arrived before the specification. And in every case the specification, when it arrives, will be written by people looking at whatever the industry was able to demonstrate in the meantime.

Which is why a containment conformance suite — one that determines whether a system can actually reach a defined safe state within a bounded time, and emits a signed report saying so, with its elicitation method declared — is an unclaimed asset rather than a compliance exercise. Nobody has built one. The capability is mandated in a bill and there is no test for it anywhere.

What I got wrong, beyond the fifteen minutes

I put revocation latency in a performance table. It sat among throughput targets and cold-start times, which is where an engineer looks and where nobody else does. It belongs in the security specification, because it is a security property that happens to be expressed in milliseconds. Filing it under performance is how it becomes the first row negotiated away when someone needs headroom.

I specified the numbers and have not measured them under load. The budgets are stated. They are targets in a specification, not observations from a loaded deployment with realistic replica counts and a partitioned network. In my own ledger that distinction is marked, and I am marking it here: these are numbers I have committed to, not numbers I have demonstrated.

That matters especially for the revocation figures, because revocation latency is exactly the kind of number that is fine on a developer machine and terrible at scale. If it degrades, it will degrade in the direction of the TTL, which is the failure this whole design is trying to leave behind.

What to check on Monday

One. Find the token or credential lifetime in your agent infrastructure. Ask what the number is for. If nobody can state the property it provides, it is a habit rather than a control.

Two. Ask what happens between the moment somebody clicks revoke and the moment the credential stops working, everywhere. If the answer is a mechanism rather than a duration, you do not have a revocation latency, you have a revocation intention.

Three. Find your revocation check and determine whether it fails open or closed when its authority is unreachable. Most fail open. That is a defensible choice for a connected enterprise and it is a different security posture than the one most people believe they have.

Four. For any physical or field process under agentic control, write down two numbers: how fast your system can begin the stop, and how long the process takes to reach its defined safe state. If the second number does not exist as a written figure, the safe state has not been defined, and the kill path terminates somewhere nobody has specified.

Five. Ask what your enforcement layer costs in throughput. Then ask whether it has ever been disabled during an incident. The second answer tells you whether the first number was acceptable.

What I am not claiming

I am not claiming time-to-live should be removed. It provides a real property, it works when coordination fails, and any design without it is worse. The argument is that it is a floor rather than a control, and that treating it as a control is how organisations end up believing they can stop something they can only wait out.

I am not claiming the numbers in my specification are achievable at every scale. They are budgets, stated to be tested against, and I expect at least one of them to move.

And I am not claiming a bill that has been introduced obliges anybody. It does not. What it does is name a capability as mandatory ahead of any test for it, which is a fact about where specifications are currently missing rather than a compliance deadline.

The invitation

This is the most concrete thing I have asked for in this series, and the one I would most like answered.

If you operate a field, plant or fleet system with automated or agentic control: measure your actual revocation latency and tell me the number.

Not the configured TTL. The measured interval between requesting revocation and the credential being unusable at the furthest node from the authority. And two more figures alongside it, if you have them: what your process's time-to-safe-state is, and what happened the last time the revocation authority was unreachable.

I have specified budgets. You have an estate. The specification is worth exactly as much as its contact with a real one, and the number that comes back from a working plant is worth more to this than another month of my reasoning.

I expect the answers to be worse than my budgets. That is the useful case.

Claims register

  • Identity revocation is budgeted at under 5s to all replicas; credential revocation under 1s · architecture document, performance budgets, and invariant I-05 · verified — in source as a specified budget
  • Kill path to a defined safe state is budgeted at under 5s end to end · architecture document, performance budgets · verified — in source as a specified budget
  • Egress mediation overhead is budgeted at under 2% of throughput · architecture document, performance budgets · verified — in source as a specified budget
  • Those budgets have been measured under load at realistic replica counts · — · unknown — not done. Stated as unearned.
  • A bounded-revocation layer is specified by execution count and release consistency rather than TTL · portfolio re-cut, additions table · verified — in source
  • Invariant I-12 requires a kill path to a known-safe state for any cyber-physical action · architecture document, invariants · verified — in source
  • No open-source project in this space publishes a revocation SLA · my search · read — a negative established by search, not exhaustive proof
  • The AI Kill Switch Act was introduced 23 July 2026, mandates four capabilities, and carries penalties reaching $20M/day · the bill, as recorded in project source after correction · read — introduced legislation, not law; never characterised as binding
  • The bill's compliance-verification format is unspecified · the bill · read
  • No containment conformance suite exists for those capabilities · my search · read — a negative established by search
  • A fifteen-minute TTL was specified in my design without a stated rationale, and corrected · my own design document · verified — in source, and the reason this piece exists

What would falsify the central argument: a deployment that can demonstrate a bounded revocation latency, measured rather than configured, that is materially shorter than its credential TTL and holds when the revocation authority is unreachable. That would mean the TTL is genuinely a floor and not a ceiling in practice, and I would want to see how it was built.