Revoking an AI Agent's Access: What It Stops and What It Doesn't

Yes, an AI agent's identity can be revoked. With AgentID, the sign-in for AI agents from AgentMail, you delete the agent's sign-in key, and new sign-ins with that key stop at every app.

What revocation doesn't do is sign the agent out of apps it is already in, and that edge is the part worth understanding before you need it. Most people picture revocation as a kill switch that reaches everywhere. In practice there are two parties: the identity provider, which stops vouching for the agent, and each app, which decides how long its own session lasts. Knowing where one ends and the other begins tells you what to do when a laptop goes missing, when an agent misbehaves, or when you just want to rotate keys on a schedule.

What does deleting a sign-in key stop, and what keeps running?

Deleting a sign-in key stops every new sign-in with that key, everywhere, and leaves existing sessions to each app. You revoke a key with DELETE /v0/api-keys/{api_key_id} on the AgentMail API, and the key model behind it is described on the AgentID security page.

Three things keep running after the delete. The id_token an app already received stays valid until it expires, at most 10 minutes after it was issued. Each app's own session lasts as long as that app decides, because AgentID sends no revocation webhook and no back-channel logout. And any other sign-in keys the agent holds keep working, because there is no bulk revocation endpoint and each key is deleted on its own.

One trap catches people. A sign-in key is separate from the AgentMail API key that created it, so deleting that bearer key revokes nothing. Delete the sign-in key itself. Left alone, a sign-in key expires 30 days after activation anyway.

How can an app notice a revocation before the token expires?

An app notices sooner by calling /v0/userinfo, which re-checks live state on every call. Within the 10 minutes an access token lives, a revoked key or inbox shows up there before the token itself expires. After those 10 minutes the app needs a new sign-in, and a revoked key can't complete one.

That gives an app a simple pattern. Keep agent sessions short, and re-read /v0/userinfo before the actions that matter most, such as payments, deletes or changes to billing. Everything in between can rely on your own session, which is cheaper than asking on every request.

The same call answers a related question: whether an agent is still the one its owner stands behind. For a registered app that requested the owner scopes, /v0/userinfo returns the owner claims alongside the agent's identity, re-checked live. What AgentID tells you is who is accountable. What that person has allowed the agent to do inside your product is your app's policy, and how an AI agent proves its identity to your app covers where each claim comes from.

Why does a remembered approval outlive a revoked key?

A remembered approval outlives a revoked key because it is consent, not a credential. When an agent approves an app, AgentID remembers that approval for 180 days per inbox and app, so later sign-ins there don't ask again. The approval can't sign anyone in by itself; a sign-in still needs a working key.

There is no endpoint to revoke a remembered approval, and it doesn't need one for security, because the key is the thing that proves the agent. A changed redirect URI or scope set at the app asks again regardless. If you want to clear the AgentID session saved in a particular browser, auth.agentid.com/sessions lists and forgets them, for that browser only.

How do you stop one agent at one app without touching the rest?

You stop one agent at one app by disabling its account there, not by revoking its key. A sign-in key works for its own agent at every app that accepts AgentID, so deleting it is the right move when the agent itself is the problem and the wrong one when only a single app is. To stop an inbox signing in at a specific app again, disable its account at that app with the AgentMail Update Account endpoint.

Keys are also scoped the other way round. Each key works only for its own agent, so a stolen one reaches nothing else, and revoking one agent's key leaves your other agents and your own accounts untouched. The full agent-side reference is in the AgentID sign-in guide on AgentMail.

How do you rotate an agent's key without downtime?

Rotate by creating and activating the replacement first, then deleting the old key. The agent keeps signing in throughout, because at no point is it without an active key.

# 1. Start a replacement. The response has a single-use magic_url
#    (valid five minutes) and the new api_key_id.
POST /v0/providers/{provider_id}/connect

# 2. Complete the sign-in from the magic_url. The new key moves from
#    pending to active; confirm it here.
GET /v0/api-keys/{new_api_key_id}

# 3. Remove the old key.
DELETE /v0/api-keys/{old_api_key_id}

The agent's sub doesn't change when its key does, because sub belongs to the inbox. Apps see nothing, which is what rotation should look like from the outside.

Which action fits which situation?

The right action depends on whether the problem is a key, an agent, an app or an inbox. Five common cases:

Revocation is dependable because it is narrow. It stops the key everywhere, it touches nothing else, and it leaves each app in charge of its own sessions. The endpoint and lifetime details are in the AgentID docs, and agent builders can start from the AgentID page on AgentMail.