Revocation cascade

A revocation cascade is the coordinated invalidation of everything an identity compromise touches: sessions, tokens, credentials, delegated agents, and active negotiations, executed as one atomic operation rather than a checklist. The goal is that no dependent grant survives the parent identity's compromise.

Cascades matter because attackers exploit the gaps between revocations: a disabled account whose refresh tokens still work, a revoked credential whose delegated agent keeps transacting. Parametric cascades map each signal type to the exact set of subsystems it must invalidate.

Making a cascade atomic is harder than listing what it touches, because the subsystems it must reach are usually owned by different teams and reachable only through their own APIs. The practical form is an ordered plan with a recorded outcome per target, so a partial failure is visible rather than silent, and a retry is possible without re-running the parts that succeeded. A cascade that reports success when three of its five targets answered is the failure this concept exists to prevent.

In agentic systems the set is not enumerable without a delegation chain, since the grants to invalidate are held by agents the compromised principal delegated to, possibly several hops away. That is what makes the chain an operational structure rather than an audit convenience: it is the query that answers what is downstream of this identity. The same reasoning applies to just-in-time capability tokens, which shrink the set that a cascade has to reach by never minting durable authority in the first place.

Cascades are also the part of an incident response that is worth rehearsing rather than documenting. The failure modes are integration failures, an expired credential on a subsystem API, a rate limit, an endpoint that changed, and none of them appear in a runbook review. They appear the first time the cascade runs against a real compromise, which is the worst moment to learn them.