An attacker captures a workload's ten-minute token — what does the short lifetime actually limit, and what does it not?

## What expiry actually bounds A short-lived token is not a small credential. For the minutes it is valid it is the **whole** of the workload's access at that audience — every table the grant allows, at full rate. What expiry bounds is how long *a copy* is worth something, which matters enormously against one kind of attacker and hardly at all against another. ## The two attackers **The attacker who found a copy.** A credential ends up in places nobody intended: a log line that dumped a request, an image layer, a crash dump, a backup, a support bundle, a screenshot in a ticket. A static key found in any of those is live — that is the defining property of the class, and it is why the same key turns up working years after it was pasted somewhere. A token found in any of those is inert, because the clock ran out long before anyone read the file. **This is the win, and it is a large one: an entire category of exposure stops producing incidents.** **The attacker executing inside the workload.** They do not need to keep a copy. The platform rewrites a valid token underneath them every few minutes, precisely so the workload keeps functioning, and the attacker reads the same file the workload does. Expiry buys close to nothing while that foothold lasts; it only starts working once you have actually removed their execution. ## What the window still costs you - **Full use, immediately.** Reads inside the window are done and the data is gone; expiry does not un-read anything. - **Derived credentials on another clock.** If the token was traded at the far side for a credential of that service's own kind, that credential has its own lifetime, which may be longer. A session opened with it may survive longer still. - **No recall.** Short lifetimes are usually chosen *instead of* revocation infrastructure, so there is generally nothing to call back mid-window. That is a deliberate trade, not an oversight. - **Replay at the addressed audience.** The audience stops the token working at other services; it does nothing to stop the attacker using it at the one it was addressed to. ## Static key against captured token | exposure | static key | ten-minute token | |---|---|---| | found in an old log or layer | still works | already dead | | captured live in flight | works until someone rotates it | works for the rest of the window | | attacker executing in the workload | holds it indefinitely | re-reads a fresh one every few minutes | | what you can withdraw | the key, once you find every copy | the grant or the identity, at the source | | what the far side records | one shared value | the workload's identity | ## What you can actually revoke You cannot call back a minted token, but two things upstream of it are yours: 1. **The grant at the far side.** Remove the identity's grant and the next token buys nothing, even though it verifies perfectly. This takes effect at the far side immediately for new calls. 2. **The identity at the issuer.** Stop minting for that identity and the flow ends at the next refresh, which is why a short lifetime is the argument that makes this quick. Both take effect within roughly one token lifetime — a ten-minute token means a ten-minute ceiling on the tail. Note the direction carefully: it is the short lifetime that makes withdrawal *fast*, not the short lifetime that *performs* the withdrawal. ## What this means when you answer the question The honest answer names both halves. Short-lived workload tokens remove the leaked-credential class outright and cap the tail after an eviction, which is why they are worth the work. They do not make a compromise cheap, they do not shrink the grant, and they do not touch an attacker who still has execution inside the workload. If someone claims the token is safe because it expires, ask them what the attacker was doing for the nine minutes it was valid, and what the far side handed back when the token was traded.