Stopping a rogue AI agent: kill switches, token revocation and what OAuth can't do yet

Most companies can switch off an AI agent's login. Ask how long the agent keeps working afterwards and you'll usually get a shrug. Drill your kill switch, put your rules in the request path and get your logs joining up before an incident makes you. This is part 2 of our agent governance series, and it picks up once the agent is running.

If you haven't read it yet, start with part 1, on owning and governing your AI agents. For giving a single agent its own login and per-task tokens, see our earlier post on agents as privileged users. Everything below assumes each agent already has an identity and a sponsor.

Picture the call. An agent is changing records it shouldn't, and someone asks you to stop it now. You disable its identity in the identity provider. A while later it's still writing to the CRM, because the token it already holds hasn't expired and the CRM never checks back.

You'll find this gap in the docs. Entra access tokens last an hour by default, and tokens in continuous access evaluation sessions can live much longer, with revocation pushed only to services that support it. Google calls a service account's access token a bearer token that works until it expires, so one of its fixes is to disable the account. OWASP lists kill switches and credential revocation as how you contain a rogue agent. Nobody claims it happens by itself.

For engineers, the weak point is step 3. A self-contained JWT gets checked locally, so the resource server never asks anyone whether it was revoked. RFC 7009 says it plainly: if the authorization server can't revoke access tokens, revoking the refresh tokendefinitionThe longer-lived token an agent trades for new access tokens. Forget to revoke it and the agent quietly keeps renewing itself. won't invalidate them right away, and you have to plan for that. Short lifetimes shrink the window. Introspection or revocation events close it, but only for the apps that use them.

Usually you can stop it signing in. That part's easy. The hard question is what still works afterwards: tokens it already holds, refresh tokens that can mint new ones, API keys in a config file, a session at an MCP server, and other agents it already handed work to.

Each platform draws the line somewhere different. Entra's guide to disabling agent identities says a disabled agent can't receive tokens or authenticate, and it keeps the identity and its metadata in your tenant. It doesn't say what happens to tokens issued before. Entra's emergency guide for user accounts has two separate steps: disable the account, then revoke its refresh tokens with Revoke-MgUserSignInSession.

AWS does it with a policy. Revoke a role's sessions and IAM attaches AWSRevokeOlderSessions, which denies every action to sessions issued before that moment. It won't work on a service-linked role. Google Cloud rejects a disabled service account's tokens straight away, but they come back to life if you re-enable it before they expire, so Google says to wait at least 60 minutes. We'd wait longer if anyone set an extended token lifetime.

Okta's Universal Logout is the closest thing to a ready-made switch, as long as the app supports it. When an admin clears a user's sessions, or an entity risk policy fires, Okta clears session cookies, refresh tokens and access tokens. Okta has also announced Universal Logout for AI Agents and calls it a kill switch for agent access. We only found that in a press release, so check your own org before you count on it.

# Entra: turn off the user account first, then kill its refresh tokens
Update-MgUser -UserId $AgentUser.Id -AccountEnabled:$false
Revoke-MgUserSignInSession -UserId $AgentUser.Id
# Entra: the agent's service principal
Set-EntraServicePrincipal -ObjectId $sp.ObjectId -AccountEnabled $false
# Any OAuth server with an RFC 7009 endpoint
POST /revoke  token=<refresh_token>&token_type_hint=refresh_token

Run it as a drill before you need it. Pick a test agent, disable it, and write down when each system last accepted a call from it. That's the time-to-revoke measure from part 1, broken out system by system. Wherever the number is longer than you'd like, you've found an app that doesn't check back.

OAuth is good at one question: did someone agree to let this client act for them? An agent that runs on its own for hours and picks its own tools stretches that. The core spec gets you a token. Its extensions are what make that token say enough about an agent, and the table below goes through where each one stops.

Scopes are the weak spot. A scope like payments:write says what kind of thing the agent may touch, and nothing about which record, how much or for which task. RFC 9700 asks for tokens cut down to the minimum privilege, restricted to one resource server and to certain resources and actions there. Rich Authorization Requests give you the field to write that down. authorization_details carries a required type plus whatever that type defines, like an amount and a payee, and the authorization server and the API enforce it together.

For chains, token exchange does more than part 1 covered. The act claim records who's acting now. The may_act claim works the other way round: it says up front which party is allowed to act for the subject, so an authorization server has grounds to refuse an exchange for an agent nobody named. Across trust domains, the Identity Chaining draft repeats the same exchange at every boundary.

Then there's theft. A plain bearer token works for whoever holds it, and a commenter on Hacker News pointed out that agents often keep plaintext credentials in memory, where a compromised session can read them. DPoPdefinitionAn OAuth standard (RFC 9449) that ties a token to a key the client holds. Copy the token without the key and it's useless. binds the token to a key, so a stolen copy fails without the private key. RFC 9700 says refresh tokens for public clients must be sender-constrained or rotated, and MCP requires rotation for public clients.

No. A sign-in proves the agent held a valid credential at that moment. It tells you nothing about whether the credential was stolen, whether someone hijacked the agent's instructions since, or whether it's now calling tools it never used before.

NIST's zero trust architecture already asks for more. Its tenets say the enterprise monitors the security posture of every asset, and that authentication and authorization run as a constant cycle of reassessing trust, with reauthentication during a session when needed. Agents need the same loop. The signals just look different.

The standards help here. CAEPdefinitionShort for OpenID's Continuous Access Evaluation Profile. Providers send each other events, like a revoked session or a changed credential, so access can change mid-session instead of at expiry. defines events one provider sends another when something changes, like a revoked session, changed token claims, a changed credential or a new risk level, and it's written for human and robotic users alike. Okta's Identity Threat Protection takes these signals from security vendors over the Shared Signals Framework, and its entity risk policy can end sessions through Universal Logout. Entra's continuous access evaluation reacts to a short list of critical events. For workload identities, that list is a service principal disabled, deleted or flagged at high risk.

One caveat from Microsoft's docs: CAE only works for some client and resource combinations, and CAE for workload identities only covers Microsoft Graph. A sign-in log full of successes can sit right next to an agent nobody's watching at the API. Part 1 noted that Entra's risky-agent detections run offline, so plan your response times around that.

Short lifetimes are the cheapest form of continuous evaluation. A commenter in a Hacker News thread about JWTs described the usual trade-off: JWTs can't really be revoked, so you set a short expiry on the access token, around five minutes, and a longer one on the refresh token. The agent has to come back to the authorization server often, and every return is a chance to say no.

Most teams already have the pieces. The identity provider logs the token grant, the gateway logs the tool call, the app logs the record change, and the model platform logs the prompt. What's missing is a key that joins them. When something goes wrong, someone ends up matching timestamps across four consoles and guessing which call belonged to which task.

Part 1's KPI table said which numbers to watch. This section is about the join. Each of the keys below already exists in a standard, so the work is carrying them through every hop and logging them in the same place.

trace_id:  4bf92f3577b34da6a3ce929d0e0e4736
agent:     agent:refund-bot-3
tool_call: call_7Qx  execute_tool refunds.create
token:     jti=9f1c  sub=user:rep-221  aud=billing
act:       { sub: agent:refund-bot-3, act: { sub: agent:triage-1 } }
policy:    allow  rule=refunds.under_limit
outcome:   201 Created  record=RF-55812

A few gaps show once you lay these side by side. A2A's spec says agents should log security events and keep audit trails for sensitive operations, and it never mentions trace context, so you'll carry traceparent through A2A calls yourself. The OpenTelemetry agent conventions are still marked Development, so pin the version you build against. The NIST NCCoE concept paper is still asking how agents can log their actions and intent in a tamper-proof, verifiable way, and how to bind each action back to a person's authorization. There's no settled answer yet.

Log the outcome too. Most agent logs stop at the tool call, and the call says what the agent asked for. The record ID, the amount and the response code say what actually changed. Without those you can't undo a bad run with any confidence.

Because a credential doesn't know its project ended. Part 1 dealt with the identity side: give every agent a sponsor and move sponsorship when that person leaves. This section is about what outlives the identity record. Think of API keys in a config file, long-lived refresh tokens, OAuth grants a user approved for an agent in some SaaS app, and a service account on a cluster nobody remembers.

OWASP's NHI top 10 puts improper offboarding first, and it splits the problem in two. Stale or dormant identities get left behind when an app or service goes offline. Orphaned ones keep working after their owner leaves, because nobody was named to take over. Its examples will sound familiar: a decommissioned service's Kubernetes cluster with service accounts still active, and an ex-employee who still gets in through an NHI after their own account was switched off.

NIST SP 800-53 already covers this. AC-2 says to tell account managers when accounts are no longer needed and when users are transferred or terminated. AC-2(3) says to disable accounts that have expired, have no associated user, break policy or sit inactive past a period you set. Agents fit every clause. The trouble is that HR events reach people's accounts, and nothing like them reaches an agent's keys.

A Hacker News commenter put the practical version simply. When keys live wherever the agent runs, it all works until a contractor leaves. That's the moment to design for, because it's the one nobody schedules.

• App registrations and service principals with secrets or certificates, and an owner who's gone or was never set
• OAuth grants and refresh tokens that someone approved inside a SaaS app. Your identity team usually can't see those
• API keys in config files, CI variables and notebooks, sitting outside any vault
• Service accounts on clusters, VMs and functions that belonged to retired projects
• MCP server and gateway allowlists that still name an agent nobody runs
• Peer agents that still take calls from one you retired. Nobody thinks to tell them

Sweep these on a schedule, and treat every hit the way part 1 treats an unclaimed agent. Then fix the cause. Tie each credential to the agent record when it's issued, give it an expiry, and make retiring the agent revoke everything hanging off it.

A lot of AI governance lives in documents. They say an agent mustn't move money without approval, or mustn't touch customer data outside its task. Then nothing in the request path checks. The rule only gets enforced when someone reads the logs afterwards, if anyone does.

NIST's zero trust model already has the parts you need. A policy engine decides and logs each call. An enforcement point sits in the request and can cut it off. For agents, that enforcement point is usually your API or MCP gateway, and the engine can be something like Open Policy Agent, which keeps its rules as code, apart from the thing enforcing them.

OWASP's agentic top 10 lands in the same place. Its cascading-failure entry wants each high-impact tool call checked against a policy-as-code rule before it runs, and an external policy engine between planning and execution. The privilege-abuse entry wants a central engine re-checking each privileged step. And MCP's tools spec says servers must enforce access controls and rate limits, and that there should always be a person able to deny a tool call.

Start with the few actions that would hurt most: payments, deletions, permission changes and messages sent outside the company. Write each one as a rule the gateway can check, with the inputs it needs. RAR's authorization_details give you a clean place to carry those inputs inside the token, so the rule and the token describe the same task.

Chains are where the runtime gaps stack up. Every hop is another place a token gets forwarded, widened or trusted too much. Part 1's rule of one token per hop is where you start, and it doesn't cover everything below.

A2A leaves a lot of this to you. It says credentials should be bound to the agent that sent the request. It doesn't define scope, validity or revocation for a credential an agent gets after hitting the auth-required state. A Hacker News commenter summarizing the OpenID Foundation's paper on agent identity listed revocation propagation as one of its open problems, next to agents impersonating users and recursive delegation.

We'd do it in this order. The drill comes first because it tells you which of the later steps matter most in your estate. Each step after it closes a gap the drill can measure again.

We start with the drill. Pick an agent, hit stop and time it, system by system. Then we fix what it turned up. Our AI agent identity and identity threat detection and response pages explain how we work, and AI governance covers the policy side.

We'd usually do the identity work on Microsoft Entra ID, Okta or Ping Identity, with agent secrets in HashiCorp Vault or CyberArk. You can bring in identity engineers for the build, or start with an assessment and see how long your agents take to stop today.