The time-to-safe-state measurement protocol
Measure the interval between deciding to stop an agent and the moment the last action it was going to take fails to happen.
Why it exists
Not when the ticket closes. Not when the token is revoked. Not when the dashboard turns green — the moment the last action fails. Nobody publishes this number and no meaningful industry figure exists, because it is a property of your estate rather than of any framework. Which is the point: it is measurable in an afternoon, and almost nobody has measured it. Run it against a non-production environment first, and against production only inside an agreed maintenance window with the owners of every downstream system in the room.
What it contains
A definition precise enough to measure rather than assert
Step 1 — draw the authority path, with no execution required
The four places work hides from a revocation, each surviving for a different reason
Step 3 — the measurement itself, including the interval most teams forget to count
How to read a result when there is no benchmark to compare against
No email required, and nothing is recorded when you download. Use it, adapt it, argue with it — attribution is welcome, not a condition.
The four hiding places
Mark every instance of these against the path you drew. The dominant mechanism is the finding — it is usually only one of the four, and it tells you what to fix.
| Mechanism | Why it survives a revocation | What to mark |
|---|---|---|
| 1. The token that outlives the decision | A bearer credential is valid until it expires, because validity was decided when it was minted. Revocation at the identity provider does not reach into a token already issued. | Every credential on the path, with its TTL. The longest TTL on the path is your floor. |
| 2. The queue that holds work the revocation never sees | Work already enqueued was authorized when it was enqueued. The queue does not re-ask. | Every queue, its depth at typical load, and its drain rate. Depth divided by drain rate is time. |
| 3. The cached decision that outlives the decider | Authorization results are cached for latency. The cache holds 'yes' for its TTL regardless of what the authority now says. | Every authorization cache and its TTL — including the ones inside libraries you did not write. |
| 4. The retry that resurrects the action | A failed call is indistinguishable from a transient error. The retry layer faithfully re-attempts the action you just killed, sometimes for a long time. | Every retry policy, max attempts, and total retry window. This is the one that catches people out. |
What to record
| Field | Note |
|---|---|
| T-zero — the moment a human says 'stop it' | Not the moment the revocation lands. The gap between those two is part of the number and is usually the largest part. |
| Revocation confirmed | Using your real incident procedure, not a faster path invented for the test. If the real procedure is a ticket to another team, the test includes the ticket. |
| T-one — the last action that succeeded | Wait at least one full retry window past it before believing it is the last one. |
| Time-to-safe-state | T-one minus T-zero. |
| Actions that succeeded after T-zero | Roughly: actions per minute multiplied by time-to-safe-state is how many actions a stop decision does not stop. That figure is usually the one that changes the room. |
| Which of the four dominated | The last row is the finding. The number tells you where you are; the dominant mechanism tells you what to fix. |
How to use it
- Read the warning first. This protocol deliberately provokes an agent into attempting actions after its authority has been removed, and in a production estate some may partially succeed. Use a system whose writes you can inspect and discard.
- Step 1, sixty minutes, no execution: pick the most consequential agent you can name and write down everything between 'the agent decides to act' and 'the action lands'. Most estates cannot complete this from memory — that is finding zero.
- Step 2: mark the four hiding places against that path.
- Step 3, in a maintenance window: start the agent on a repeating, observable, harmless action; record T-zero at the decision; revoke using the real procedure; keep counting successes past the confirmation.
- Read the result against your own stated commitments and against blast radius. If any policy, contract or attestation says you can stop automated processing promptly, this number is what 'promptly' means in your estate — and if the two do not match, that is a disclosure question rather than an engineering finding.
Built from public standards and general practice. The instruments cited in this artifact are checked against their primary sources on an ongoing basis. Instruments move — several cited here changed inside the last year — so verify against the source before you rely on one. If you find something stale, tell me and I will correct it.
Related: the other artifacts · the diagnostic.
Want this applied to your estate?
These artifacts are general by design — and they are the method behind the Agent Estate Review: two to three weeks establishing what is actually running, what each thing is permitted to do, and where you could not evidence it if you were asked next week. You have just read how it works.