The article discusses the overlooked timing gap in revoking access for AI agents, highlighting how cached credentials and side effects can lead to unintended actions after revocation, and proposes measuring this delay as a critical metric.
Access control in agent stacks gets discussed as a question of who gets what. How long the answer takes to change is barely discussed at all. Revocation is a write on the issuing side. Enforcement is a read on the consuming side. Between those two events sit cached tokens with TTL left on them, already-open sessions, queued jobs carrying credentials, sub-agents that were spawned with a copy, retries holding stored parameters, and tool calls already in flight at the provider. With human users this gap is easy to miss. Revoke someone's access and they are probably asleep, or halfway through typing a sentence. An agent can do more inside that same fifteen minute window than a person does in a quarter. Most teams verify that the revoke API returns 200. What they usually cannot produce is t_stop: elapsed time from revoke to the last successful privileged call. It's a real number and you can measure it in an afternoon. Kick off a loop, revoke mid-run, then go find the timestamp of the last call that still succeeded. I could be wrong about how common this is, but I'd guess most stacks have never generated that number even once. The obvious fix is shorter TTLs, and then the refresh path quietly becomes the real authority. If the agent can refresh, revocation has to reach the refresh check, and that check tends to be the one nobody tests under load. Long-running jobs make it worse. People raise the TTL back up, or add a rule like "renew while the job is healthy," which can re-grant credentials during exactly the incident you were trying to stop. Shrinking t_stop is not free either. You move from a cached local decision to a per-call check, so every privileged action now depends on the authorizer being reachable. Fail open and you did not revoke anything. Fail closed and your authorizer becomes an outage amplifier. That tradeoff is the actual design question. The TTL value is downstream of it. The part that seems least measured: there is a separate t_stop for every side effect. Credentials might stop working in seconds while a queued job that already carries the outcome fires later. A message sits in a send queue. A payment record with an idempotency key gets honored whenever it lands. Access is gone and the outside world still changes. So the honest measure is time from revoke to last externally visible effect, which usually spans two systems, which usually means nobody owns it. Has anyone actually measured this? Curious whether your stack could even answer the question today.
The article highlights the growing problem of managing AI agent memory over time, where users spend more effort maintaining context than actually using the agent, and points out the lack of infrastructure for memory decay and governance.
The article outlines five key practices that differentiate successful long-running AI agent setups, emphasizing orchestration, chartering, proportional access, correction storage, and reversibility-based approval lines.
A discussion on the lack of processes for retiring AI agents, focusing on how to decide when to shut down an agent, track usage, and who should make the kill call.
The author shares lessons from putting an AI agent with write access into production, explaining that retry logic inside the agent loop fails when the process dies. They advocate for treating side-effectful tool calls as durable background jobs with idempotency keys.
Discusses the overlooked problem of memory hygiene in AI agents, where long-term storage leads to stale and unreliable context, and questions whether the industry is ignoring a looming global issue.