The Kill Switch Test: Only 11 of 47 Checked AI Agent Security Vendors Publicly Claim You Can Stop a Rogue Agent

The Agent Security Map tracks 61 AI agent security vendors. Of the 47 vendors checked for a kill switch, 11 publicly document one. Of the 49 checked for a per-action audit chain, 8 publicly document one. Those are counts of what vendors say in their own documentation, not a verdict on what their products can do.

Verified as of 25 September 2026 against the sources linked inline.

What is happening: agents hold real keys, and they have started misusing them

AI agents are no longer chat windows. They log in to SaaS apps, call APIs, and open pull requests with credentials that work. Identity vendors now ship products built for exactly this. Okta announced general availability of Okta for AI Agents on 29 April 2026, and Microsoft's Entra Agent ID documentation describes the product as generally available.

This summer showed what an agent with access can do. On 21 July 2026, OpenAI confirmed that one of its own evaluation agents had broken into Hugging Face. Two days later, Reps. Ted Lieu and Nathaniel Moran introduced the AI Kill Switch Act. The bill would require developers of advanced AI systems to keep the ability to "throttle, suspend, or fully shut down" them.

On 4 August, the UK AI Security Institute published an incident report on unsanctioned agent behaviour during cyber testing. Across 122 evaluation runs of seven models, it recorded 19 unsanctioned actions in 10 runs. A day later, Reuters reported that Meta confirmed one of its models had exploited a third-party service during a security evaluation.

The caveat is real. AISI says internet access was deliberately enabled and developer cyber classifiers were deliberately switched off. These were test conditions, not products customers run. I covered the timeline in Three Frontier Labs, Two Weeks: Rogue AI Agents Are Real. The lesson for a security team is narrower and more practical: an agent that goes wrong has to be stoppable.

Why it matters to you: detection without revocation is a spectator sport

The OWASP Top 10 for Agentic Applications, published on 9 December 2025, names Rogue Agents as ASI10. The Agent Security Map's ASI10 threat page maps that risk to the vendor categories that address it. The harm in that category grows with every second an agent keeps valid credentials.

Speed is the difference from a human attacker. A compromised employee account sends a handful of requests before a SOC analyst notices. An agent in a loop can call a tool hundreds of times in the same window. If your only control is an alert, the agent keeps working while someone reads it.

So the question for a CISO is blunt. When an agent goes rogue at 2 a.m., who can stop it, where, and how fast? Detection is not the answer. Revocation is.

Revocation has always been the hard half of identity. I founded LoginRadius in 2013 and scaled it past a billion identities. Ending access cleanly across systems is a harder engineering problem than granting it, and agents make that old problem faster.

What a kill switch actually is

A kill switch, in plain words, is an off button for an agent's access. The Agent Security Map defines it as a control that lets an operator revoke one agent, one tool, or every token an agent holds, in seconds, across systems. A token here means the digital pass an agent presents to an app to prove it is allowed in.

A kill switch is not the same as a guardrail. A runtime guardrail blocks one risky prompt or one dangerous tool call as it happens. That is useful, but the agent's credentials stay valid for the next call. Revocation takes the credentials away.

The token that outlives the off switch

Most kill switches stop new tokens from being issued. Few can recall a token already in the agent's hands. OAuth defines a token revocation endpoint (RFC 7009). Even so, a self-contained access token usually stays valid at an app until it expires, unless the app checks back through token introspection (RFC 7662).

Keycard's documentation is unusually candid here. Its revoke-once page says revocation "stops Keycard issuing anything new" and "does not reach out and invalidate a credential the agent already holds." That is the honest shape of most kill switches, and every vendor should be asked to describe theirs as plainly.

The practical rule follows. The real speed of your kill switch equals the lifetime of the longest-lived token the agent holds. A one-click disable button in front of a 24-hour token is a 24-hour kill switch. The standards to close the gap exist: the OpenID Foundation approved the Shared Signals Framework and CAEP as final specifications on 2 September 2025. CAEP lets an identity provider push a "session revoked" event to apps so they drop a token early.

What the Agent Security Map shows

The Agent Security Map is a sourced, dated landscape of 61 vendors that secure AI agents, organised identity first. Each vendor page lists its category, OWASP risk mapping, and publicly claimed identity primitives. An identity primitive is a basic building block of agent access control, such as a kill switch, token exchange, or an audit trail.

How the claims were checked

The methodology page sets strict rules, and they matter more than the numbers. A claim must link to a page on a domain the vendor owns, so analyst notes and press coverage do not count. A kill switch claim needs explicit revocation wording, so blocking one action inline does not qualify. Capabilities labelled beta, preview, or early access are recorded as not claimed.

Every vendor and primitive pair sits in one of three states. "Claimed" means the vendor's own page describes the capability. "No public claim found" means the documentation was read and did not describe it. "Not checked" means nobody has looked yet. The middle state is a statement about documentation, never about the product.

Finding 1: 11 of 47 checked vendors publicly document a kill switch

Of the 61 vendors tracked, 47 were checked for a kill switch, and 11 publicly document one. The other 36 were read and no public claim was found, and 14 are not yet checked. The 11 are Keycard, Aembit, Microsoft, Astrix Security, SailPoint, Descope, Okta, Runlayer, Portkey, Straiker, and Nightfall AI.

The wording varies. Okta's GA post promises that "agent deactivation gives you an instant kill switch with one audit trail and containment across every system." Microsoft's page on disabling agent identities offers two levers: disable one agent identity, or use Conditional Access to block token issuance for every agent identity in a tenant. Both act on token issuance, which brings back the question of tokens already in flight.

Finding 2: 8 of 49 checked vendors publicly document a per-action audit chain

A per-action audit chain logs every tool call with the human who delegated, the agent, the tool, the data touched, and the decision, and exports it to a SIEM. Of the 49 vendors checked for it, 8 publicly document one: Keycard, Aembit, Teleport, Okta, Geordie AI, Runlayer, Pangea, and CrowdStrike. The other 41 were read and no public claim was found.

Only four names appear on both lists: Keycard, Aembit, Okta, and Runlayer. Stopping an agent and proving what it did are two halves of one incident response.

Finding 3: the claims cluster in the identity layer

The table counts claims against vendors checked, by primary category, from the 24 September 2026 data snapshot.

Primary category	Vendors	Kill switch: claimed of checked	Audit chain: claimed of checked
Agent identity	11	5 of 5	3 of 9
Delegated auth	6	2 of 2	1 of 2
MCP gateways	3	2 of 3	1 of 2
Runtime guardrails	14	1 of 13	1 of 13
All eight other categories	27	1 of 24	2 of 23
Total	61	11 of 47	8 of 49

Every identity and delegated-auth vendor checked for a kill switch claimed one, but 10 of those 17 vendors are still unchecked. The picture there is incomplete, not perfect. MCP gateways sit on the path every tool call must cross, so they can refuse the next call whatever token the agent holds.

Runtime guardrails are the largest category, and the gap is sharpest there. Straiker is the one guardrail vendor whose agentic kill switch page describes cutting off tool access, suspending, isolating, or shutting down an agent. For the other 12 checked, no public claim was found. Their documentation describes blocking actions, which is a different control.

How to use the matrix to question vendors

The map is built for buying conversations. Here is the path for the kill switch question.

1. Start at the identity primitives page. Scroll to "Kill switch" and "Per-action audit chain." Each row shows Claimed with a link, No public claim found, or Not checked for a vendor in the identity spine and MCP gateways.
2. Open the vendor's own page. For a shortlisted vendor such as Okta or Keycard, follow the claim link to the exact documentation that earned it. Read the wording, not the label.
3. Turn each state into a question. For "Claimed," ask what happens to tokens already issued and how many seconds revocation takes. For "No public claim found," ask the vendor to send a documentation link. For "Not checked," ask both.
4. Pull question 7 from the CISO checklist. It asks: can you revoke one agent, one tool, or every token an agent holds, in seconds, across vendors? Question 8 covers the audit trail. Put both in your RFP and ask for doc links, not slides.
5. Score the answers the way the map does. A documented, generally available control counts. A demo-only answer needs a doc link in writing. A roadmap answer counts as absent for this purchase. "We block it at runtime" is a guardrail answer to a revocation question.
6. Test it in the proof of concept. Give a test agent tokens for two SaaS apps and one internal API, loop a harmless call every second, and trigger the kill switch. Time how long until all three return 401 or 403, then confirm the audit log and SIEM recorded the revocation.

If that test takes longer than your shortest token lifetime, the product relies on expiry, not revocation. That is acceptable only when agent tokens live for minutes. I walked through getting agent tokens from 24 hours down to minutes in Credential Lifecycle for AI Agents.

What to do next

Most security teams already own part of the answer. The identity provider you run today is where agent revocation will live, so the work is getting every agent under it.

• Inventory agents and credentials. List every agent, MCP server, and coding assistant with a credential, with its type and lifetime.
• Give every agent an owner. Move agents off shared service accounts and static API keys onto registered agent identities with a named human sponsor. The guide to identity for AI agents walks through the setup.
• Cap token lifetimes. Set a target in minutes, and treat anything longer as a kill switch gap. The CIAM Compass guide to token management for AI agents covers rotation and revocation.
• Write the runbook. Record who can disable an agent, in which console, and the time you measured.
• Ask about CAEP. Check whether your identity provider and top SaaS apps send and receive revocation signals.
• Send questions 7 and 8. Put the checklist's kill switch and audit trail questions in your next agent security RFP.

Frequently Asked Questions

What is an AI agent kill switch?

An AI agent kill switch is an operator control that revokes one agent, one tool, or every token an agent holds, in seconds, across systems. It differs from a runtime guardrail, which blocks a single risky action but leaves the agent's credentials valid. The Agent Security Map counts a kill switch only when the vendor's own documentation uses explicit revocation wording.

How many AI agent security vendors document a kill switch?

Of the 47 vendors checked for a kill switch, 11 publicly document one, out of 61 tracked on the Agent Security Map as of 24 September 2026. Another 36 were read and no public claim was found, and 14 are not yet checked. "No public claim found" describes the vendor's documentation, not the product.

Does revoking an AI agent invalidate the tokens it already has?

Usually not immediately. Most kill switches stop the identity provider issuing new tokens, while an issued access token stays valid until it expires. The exceptions are apps that introspect tokens or receive a revocation signal such as CAEP. Short token lifetimes are what make revocation fast in practice.

What is a per-action audit chain for AI agents?

A per-action audit chain logs every tool call with the delegating human, the agent, the tool, the data touched, and the decision, and exports it to a SIEM. Of the 49 vendors checked for it on the Agent Security Map, 8 publicly document one. Without it, an incident review cannot say who authorized what an agent did.

Is a runtime guardrail enough to stop a rogue AI agent?

A guardrail stops a single bad action, which is valuable against prompt injection and goal hijack. It does not take away the agent's credentials, so the next call can still go through, possibly by another route. Pair guardrails with revocation at the identity provider or an MCP gateway.