Welcome to the Kill Switch. We’ve Been Here a While.

An AI kill switch made headlines this week, I'm sure you saw... but can it? Are those headlines telling the entire story? 

On November 3rd, an endpoint security vendor showed up in Barcelona and announced they had "The kill switch". But do they? I mean really? If you have deployed agents or have a very minimal experience with where agents live, how they operate, especially on behalf of a human...do they really have a kill switch? 

I can tell you they do have a marketing budget to get their story in the headlines...

I wake up to my agent-generated feeds, turn on the TV, and listen to a podcast talking about this vendor having an agent kill switch... Their pitch: when an agent goes rogue, an administrator can stop it, keep it from relaunching, and cut its network access.

I agree with the premise. If you give an agent the ability to do things, you need a way to take that ability away.

But actually read their press release...

“Stop the agent” could mean killing a process. It could mean blocking the next model request. It could mean ending a session or refusing to issue another token. These are different controls, they stop different things. This is where this gets interesting, because I've been building and publishing a real "kill switch" since April.

On April 17, I published a working implementation where a signed event triggered session termination across the connected systems. On May 26, I published the cookbook, code included: “Shared Signals and the Kill Switch.”

This isn’t another launch announcement. It’s a look at what I built, what the antenna stops, and the questions I’d ask anyone trying to sell me a kill switch: Once the kill switch is activated, what can the agent still do? Better yet, what else is still out there, what is the blast radius? 

Read the press release

The promise is to “contain rogue agents wherever they operate.”

As I would think, because I have been talking to customers daily, blogging, ACTUALLY implementing, the November 3rd post and press release describe what I would say a limited starting point.

Per the vendor, at launch, the switch tells connected AI gateways to block the agent’s access to its models. The agent’s code stays where it is. Really? This is what you call a kill switch? 

Other capabilities are described as coming:

• Killing the process on the endpoint.
• Containment in cloud, SaaS, and browser environments.
• Revoking the agent’s permissions at runtime.
• More automated response workflows.

An authorized administrator pulls the trigger on the initial control. Enforcement starts at the gateway, with sensor-based endpoint capabilities described as coming. This plays right into the the vendors AGENT heavy deployment and requirement. We saw what happens when that network goes down....do we really want to rely on the one vendor and agents? Wouldnt it be better to stick to standards and not need agents everywhere?

So blocking access to a model leaves an obvious question: what happens to the credentials the agent already has? OR tokens in flight...think ID-JAG token..no requirement for the check of the original issuance of the id-jag token. Now add in, bad practice, does its API key still work? Can it still query the database? 

I would be asking this before buying or even wasting your time with a session.

Here’s what IBM has already proven, here is what I have already built..

I’ve published the implementations and shown the flow live at the Gartner IAM Summit, IBM THINK, RSAC, Identiverse and TechXchange 2026

IBM Verify Antenna is a shipping, documented product with published starter recipes. It also passed the OpenID Foundation’s interoperability test of the final Shared Signals and CAEP specifications in October 2025, as both transmitter and receiver, over both push and poll.

The point of those posts was to show the whole flow, including the timing, the integrations, and the things that don’t stop just because one system says “revoked.”

Make the agent come back for permission

The important part of this design isn’t the switch. It’s the fact that we are using the AGENT INTENT...yes the INTENT. The agent has to keep coming back for authority. We will know what that agent is trying to do, is it allowed? is it on behalf of? what are the details? 

Here’s how that works.

Every tool call goes through identity

In this implementation, each tool call uses an RFC 8693 token exchange carrying an RFC 9396 rich authorization request.

The agent doesn’t hold a standing backend credential. It gets a token for the call, and the Vault credential behind it has a ttl lifetime and we can create a one time ephemeral credential. We can get granular...I dont want my agent able to access a celebrity record without consent, or without proper control and compliance..guess what..we can do this.

This gives us somewhere to enforce the decision. Suspend the agent, and its next attempt to get a token fails.

But that only works if the agent actually needs a new token. Give it a cached credential and a route around the exchange, and you’ve left another door open.

More on that in a minute.

Anything can raise the alarm. Antenna handles the response.

The signal can come from an OPA guardrail, a risk engine, the mcp server, gateway, or really anything issuing CAEP SET events. If you do not have this yet... fine- webhook event or a log; we can ingest pretty much anything. This is the beauty of the antenna. A configured action rule decides what happens next.

I don’t need to make the gateway an identity administrator just so it can tell me something went wrong.

Antenna delivers the event and runs the response

For any event, IBM Verify Antenna signs it as an RFC 8417 Security Event Token. The receiver processes it through the Shared Signals integration and applies an action rule.

In my configuration, that rule:

• Deletes the user’s sessions in Verify.
• Calls the upstream IDP’s revocation API.
• Suspends the agent in the IBM Agent Identity registry.
• Invokes the configured Vault-side action. Which will kill that last mile credential request.
  
  TRUE KILL SWITCH

One event kicks off several actions. They don’t all finish at the same time, and they don’t all stop the same thing.

Also, the standard isn’t doing magic here. The signed event carries the signal. The integrations and action rules do the actual work.

Sometimes you want to stop the run. Sometimes you want to stop the agent.

Those aren’t the same decision.

A session kill says, “This run is over.” An agent suspension says, “Don’t give this agent new authority, no matter who it’s acting for.”
Maybe a user’s session is compromised, but the agent is fine. 
End the session.

Maybe the agent has a bad configuration or is doing something you don’t trust.
Suspend the agent.

The implementation supports both. When someone says their product can “kill an agent, " what are they really stating? 

What about knowing when to pull it?

This morning, one of our developers walked me through where this is heading, and it covers things I hadn’t really thought about.

Threat detection in IBM Verify builds a baseline, if an agent’s token issuances or denials drift away from that baseline, or something starts creating a pile of agent registrations through one API client, that becomes a risk.

The risk rolls up to things I can act on: the client, the agent, the application, and in an on-behalf-of flow, the user. From there, a policy can respond on its own. we can disable the client or agent and revoke its sessions.

We can enable this to be autonomous or an admin/soc can review the traffic and make the call. Once the risk is mitigated, it drops off the dashboard.

Just another feather in our IBM Agent Identity hat. 

The runtime isn’t the common part

I’ve run this chain with an agent:

• On a laptop.
• In an OpenShift sandbox.
• On AWS Bedrock AgentCore.
• As a hosted Claude agent.

What made it work wasn’t where the agent ran. Each integration required the agent for each tool call to prove its intent. 

Register the agent in IBM Agent Identity, which then registers it in Vault, and it doesn’t matter if it runs on Bedrock, on Claude, on watsonx, or in something your enterprise built itself. Suspend it at that point and no new tool call on that path makes it through. To me, that’s a true kill switch.

That’s the claim. Not “identity can stop any code anywhere.”

You don’t have to replace your IDP

My published integrations use Verify, Microsoft Entra, and Okta, Keycloak, whatever IdP.

Verify validates the upstream identity. When the kill event arrives, the Antenna action rule reaches back to the upstream provider using Microsoft Graph’s revokeSignInSessions or Okta’s user-session deletion endpoint, we can basically kill any session anywhere and the same with the agent.

The signal can run the other way, too. Rajeev Kumar wrote up an Auth0 integration back in October 2025. Antenna pulls the Auth0 logs and turns something like a blocked high-risk user into a Shared Signals event, and the receiver can then disable that user in IBM Verify and log them off.

Questions to really ask....

1. What does it stop today, and what’s still on the roadmap?
2. What can the agent or the gateway or the downstream mcp server do with credentials it received before the kill?
3. What still works when the agent runs outside your managed endpoints?
4. Can it reach the IDP your users signed in with, and how long does that revocation take?
5. Can policy trigger the response, can another system receive the signal, and can you show me the next action being denied?

We’ve been publishing and demonstrating the identity path since April. The cookbook is public.

And to our friends in Barcelona: welcome. There’s plenty of work left.