Revoke in seconds: the kill switch agents actually need

Every credential has a half-life. The question that matters when something goes wrong is: how fast can you make it stop?

For a human-facing system, "rotate the key and redeploy" is an acceptable answer — incidents are rare and a person is usually in the loop. For an agent that takes hundreds of actions a minute, it is not. By the time you've pushed a config change, the agent has already done whatever it was going to do, dozens of times over.

Self-contained tokens can't be un-issued

The reason revocation is usually slow is the credential design. A self-contained token — a signed JWT, an API key checked only at the edge — carries its own authority. Once issued, it is valid until it expires, and nothing the issuer does after the fact reaches it. Your only real levers are a short expiry (which means constant re-issuing) or a denylist that every checker has to consult (which is just server-side checking with extra steps).

So teams pick a TTL and hope the blast radius between "something's wrong" and "the token expired" is survivable. For an agent, it usually isn't.

Opaque tokens move the decision to the server

AgentTrust ID issues opaque tokens — at_ references that carry no standing authority on their own. They aren't a signed claim the holder can present and have trusted; they're a handle the server looks up on every use. Introspection happens server-side, against live state, at the moment of the call.

That one design choice changes what "revoke" means. Because authority lives on the server, not in the token, pulling it is immediate and global: the next introspection returns inactive, everywhere, with no propagation delay and no waiting for a clock to run out. "Stop" becomes a single call instead of a deploy.

It also means revocation is precise. You can cut one agent's token without touching the others, because each is its own server-side record — not a shared secret you'd have to rotate for everyone at once.

Why this matters for agents specifically

Agents fail in ways static systems don't: a prompt injection redirects a goal, a tool returns something unexpected, a planner loops. You won't always predict these in advance — which means your safety net can't depend on having set a short-enough expiry ahead of time. It has to be something you can pull now, the instant a dashboard or an alert tells you something looks wrong.

A kill switch you have to wait on isn't a kill switch. Making revocation a real-time server decision — not a property baked into a credential at issue time — is what turns "we noticed" into "we stopped."