A customer asks an assistant to sort out a supplier invoice. The assistant hands the job to a payments agent. The payments agent calls a ledger service to send £48,000.
Halfway through, someone notices the invoice is fraudulent and hits the kill switch on the assistant. The assistant stops. The payments agent, which already has its instructions and its own access to the ledger, carries on. The money goes.
That is what an AI agent kill switch does in most estates today: it stops the agent you point it at, and nothing that agent has already set in motion.
A task is rarely one agent
The mental model most teams still carry is one assistant calling one tool. That stopped being accurate as soon as agents could delegate.
A single request now tends to become a chain. An assistant calls a specialist, the specialist calls another agent or a handful of services, and some of those services are agents too. In the reference agent estate we build and test KPATH against, almost every session touches more than one service, and the busiest sessions involve more than a dozen agents.
That changes what “stop” has to mean. The unit you need to control is no longer the agent. It is the piece of work, and everything that piece of work has spread into.
Why most kill switches stop at one agent
When something goes wrong, teams usually reach for one of three levers. Each has the same blind spot.
Disable the agent in its platform. The agent stops taking new requests. Anything it has already delegated is running somewhere else, often on a different platform, owned by a different team.
Revoke or rotate its credential. New calls from that agent fail. The downstream agents hold credentials of their own, so they are unaffected. Short-lived tokens already issued can keep working until they expire.
Pull the deployment. Slow, blunt, and it still only covers the one agent you pulled. By the time a rollback finishes, a machine-speed chain has usually finished too.
The common flaw is that each lever acts on a single agent, while the risk lives in the relationships between agents. Nobody holds a live picture of which agent invoked which, so there is nothing to tell the kill switch where the rest of the work went.
What stopping the whole chain actually takes
Containing a multi-agent incident properly needs five things. Most tooling has one or two of them.
1. See the chain as it forms
Something has to record, call by call, that the payments agent is acting on behalf of the assistant, which is acting on behalf of a customer request. That record has to exist before the incident, not be reconstructed from logs after it.
2. Stop it on the call path, not inside the agent
If the stop depends on the agent noticing and complying, a compromised or confused agent will not comply. The control has to sit where the agent’s calls must travel, so that a stopped chain is refused at the door whatever the agent decides to do.
3. Cut off the chain’s credentials
Stopping calls is half of it. The credentials the chain was relying on need to be withdrawn too, so the stopped work cannot pick them up again.
4. Hold even while you are only watching
Plenty of teams run agent governance in a monitor-only mode while they build confidence. A kill switch that only works once you switch to full enforcement is no use during that period, which is exactly when you are least sure what your agents are doing. A stop should stop in every mode.
5. Prove the stop held
This is the part most often missing, and the one an auditor or regulator will ask about.
Proving the stop held
After an incident, “we hit the kill switch” is a claim. The question that follows is harder: can you show that nothing in that chain was authorised after the moment you stopped it?
A debug log does not answer that. Logs can be incomplete, and anyone reviewing them has to trust whoever produced them. A log you control is not evidence. What you want is a record that is tamper-evident and can be checked independently, covering every call that descended from the stopped request, with the stop itself on the record.
With that, the post-incident conversation changes. Instead of explaining what you believe happened, you hand over evidence that the incident was contained at a specific moment, and that every later attempt by any agent in the chain was refused.
If your agents touch customer money or regulated data, that difference carries past the incident itself. Showing a supervisor a contained incident is a much stronger position than describing a kill switch.
Questions to ask about any AI agent kill switch
If you are evaluating agent governance tools, or reviewing what you already run, these questions separate a real containment capability from a stop button.
- When I stop an agent, what happens to the agents it has already called? If the answer is “they keep going”, you have an agent switch, not a chain switch.
- Does the stop work across frameworks and platforms? Chains cross team and vendor boundaries. A switch that only reaches agents on one platform misses the part of the chain that usually matters.
- What happens to credentials the chain was using? The chain should lose them as part of the stop, not on their normal expiry.
- Does it work in monitor mode? It should.
- Where is the decision enforced? Inside the agent, or on the path its calls must travel? Only the second holds against an agent that has been manipulated.
- What can I show an auditor afterwards? Look for a record anyone can check, not a log someone has to vouch for.
- Can I see cost the same way? The chain that caused an incident is often the chain that caused an unexpected bill. Rolling spend up to the originating request shows which piece of work was responsible.
How KPATH handles it
KPATH sits on the path between agents and the systems they reach. It tracks the chain as each agent calls the next, and it can refuse a call from an agent that should be part of a chain but arrives outside one. That gives it the chain before anything goes wrong.
One action stops the chain: every agent and action descending from that request. The chain loses the credentials it was relying on, and the stop holds in monitor mode as well as in enforcement. A single agent can also be switched off on its own. Afterwards, KPATH produces a record anyone can check, showing that nothing descending from the stop was authorised after it.
You can see the containment model, and the difference between revoking one agent and stopping the chain, on the whole-chain kill switch page.
Where to start
Most organisations do not yet know how their agents chain together, which makes the first step straightforward: map it. Run in monitor mode, let every call through, and watch the real chains form across teams and platforms. You will learn which agents delegate to which, which ones reach money or regulated data, and where a single stop would currently leave work running.
Then decide what to enforce.