In short, in the five weeks to 27th October 2026, Okta, Satya Nadella, the Cloud Security Alliance and Salesforce each put the words “kill switch” or “emergency brake” next to AI agents, and the AI Kill Switch Act, introduced in the US House on 23rd July, would require the largest model providers to be able to throttle, suspend or shut their systems down on order. Every one of those switches stops something, and none of them stops the same thing. Pull the switch on an agent in your cluster and read what is still true a minute later: the Deployment has replaced the pod, the callers are retrying, the open sessions are still open, and the key in the agent’s environment still works. A kill switch for a fleet is a set of cuts at points the agent does not control, and the only way to know which ones you hold is to pull them. This post reads the bill and the UK NCSC’s advice for what a stop has to do, runs a drill through the five switches teams reach for, then says what a governance layer like Tigera Lynx can and cannot do about it. It is written for the platform and security leaders who would be told to stop an agent at nine and asked at five past what it was still doing.
On 22nd September 2026, Okta announced that it was “expanding the Kill Switch to revoke active tokens at the Agent Gateway,” and described the switch it already had: “deactivating an agent through the admin console immediately blocks new sessions.” Revoking “every active token held by a compromised agent” and shutting down “every session in flight” is the version planned for the fourth quarter. On 10th October, Satya Nadella wrote that companies should treat frontier models as insider risks and asked for an emergency brake: “An authorized person should always be able to pause or shut down a model mid-task.” On 16th October, Pravin Kothari of PointGuard AI argued on the Cloud Security Alliance’s blog that the agent kill switch is no longer optional, with a caveat the title left out: “A kill switch is the final control, not the entire strategy.” And on 27th October, Salesforce announced that its Agent Kill Switch is generally available, that the version which fires on its own when an agent fails an evaluation is due in January 2027, and that both exist because “agents can fail silently, delivering wrong answers and racking up costs before anyone notices.”
The phrase comes from Congress. On 23rd July, two days after OpenAI disclosed that its evaluation agents had reached Hugging Face’s infrastructure, Representatives Ted Lieu and Nathaniel Moran introduced H.R. 9917, the AI Kill Switch Act. It would require a covered entity, one earning “not less than $500,000,000 in gross revenue” from a model that took more than $100,000,000 of compute to build, to maintain the technical capability to “Stop inference,” “Terminate user access,” “Suspend access” for a flagged account or use pattern, and “Shut down such technology,” and it would let the Secretary of Homeland Security order any of those, at up to $20,000,000 for each day an order goes unmet. The bill went to the Committee on Homeland Security that day and to its Subcommittee on Cybersecurity and Infrastructure Protection the next; as of 20th October 2026 the status record lists nothing after that. Four weeks later, on 20th August, the UK’s National Cyber Security Centre published interim advice on agentic AI whose seventh and last consideration is addressed to the people who run agents rather than the people who serve models: “If an incident is detected or reported, you should always be able to ‘pull the plug’ and halt autonomous AI agent activity immediately.” The next sentence is the one to keep: “This may mean more than stopping the agentic AI processes.”
None of this is theater, and the bill’s drafters understood the problem better than its name suggests. Its definition of a covered incident includes “Sabotage of, or interference with, a lawful instruction to shut down a covered technology” and “Concealment of a capability, intention, or action of such technology, by such technology, from a monitoring or shutdown mechanism.” Read that as an engineering requirement and it is specific: a switch the system can reach is not a switch, and the moment it is reached is the incident. Lieu said it in plain words at the introduction: powerful systems can “resist human intervention.” The vendors shipping switches this quarter are building the right thing.
But the bill is addressed to the companies that serve models, and the brake Nadella describes stops a model mid-task. What runs in your cluster is a fleet: Deployments that call models with keys from their environments, call tool servers, call each other, and pull work from queues. We asked in Would you notice? whether anything you run would know an agent was there. The next question is harder. Say you knew, at nine on a Tuesday morning, and you pulled the switch. What is still running at 09:01?
What does “kill switch” mean in the bill, and in the guidance?
The bill names four capabilities and a framework. The capabilities are the ones above. The framework is the more useful part, because it is graduated: the Secretary is to consider “a graduated deployment-corrections framework” with measures “calibrated to the severity and immediacy” of the risk, and the bill lists five of them: “Throttling or otherwise altering” the inference rate, user access or compute; “Disabling or restricting a capability”; “Suspending”; “Shutting down”; and “Transitioning an operation dependent on such technology to a backup system or an earlier version.” That is a dimmer with five positions rather than a switch, and each position is a different control.
The NCSC’s version is shorter and says where the controls have to sit. “Your controls should cover the wider system, allowing you to rapidly restrict network access to the agentic AI infrastructure and interrupt the communications between selected AI agents and the AI model inference infrastructure.” That names two cuts: the network around the agents, and the path between a chosen agent and the model. Neither is inside the agent.
Three things about those two documents are easy to get wrong.
The bill is written for the people who serve the model, not the people who run agents against it. A covered entity makes the technology “available to a third party through a programmatic interface, hosted service, or other similar mechanism” and earns half a billion dollars a year from it. Unless that is you, the law would require nothing of you. The capability it describes is the one you need anyway, and the NCSC says so to operators directly.
“Shut down” in the bill means stop serving the model. In your cluster, the model is somebody else’s server. You cannot stop a provider’s inference, and you would not want to, because the agents you have not stopped need it. What you can stop is one agent asking, which means the switch has to tell one agent from another, on every request, at a point the agent passes through. That is an authorization problem wearing a safety label.
Neither document puts a number on “immediately.” The bill’s orders are carried out “as soon as practicable” and its incident reports are due within 15 days; the NCSC says “immediately” and leaves it there. So the number is yours, and the useful one is how long after the flip the agent is still doing something, rather than how long the flip takes.
What is still running after you pull it?
Set the drill up with one agent, because one is enough to show the shape. Call it triage. It runs as a Deployment with three replicas in the support namespace, reads a provider key from a Secret, calls two MCP servers (ticketing and customer records), is called by a second agent named escalation, and pulls work from a queue. At 09:00 somebody decides it has to stop. Here are the five switches teams reach for, in roughly the order they reach for them, with what each one leaves running.
| The switch | What stops at 09:00 | What is still true at 09:01 |
|---|---|---|
| Delete the pod | One process, for a few seconds | The Deployment has replaced it with the same image, key and instructions. Scale it to zero and the pods stay gone, but the key is still valid wherever it was copied, the queue still holds its work, and escalation is retrying against a Service with no endpoints and will page someone about it |
| Revoke the provider key | Every model call, with a 401 | The MCP and agent-to-agent calls, which never used that key. An agent with tools and no model does not stop; it errors and retries, or falls back to whatever else is in its environment. If six agents shared the key, six agents stopped, five by accident |
| Deactivate the identity | New sessions and new tokens | Every session already open and every token already issued, until each expires. Okta’s own release draws the line: deactivation “immediately blocks new sessions,” and shutting down “every session in flight” is the expansion planned for the fourth quarter. An identity switch is a switch on issuance, and the agent you are stopping is already past it |
| Deny it at the gateway | Every call that passes the gateway, in both directions, from the next request | Every call that does not: a direct connection to a provider, a model you host in the cluster over plain HTTP, a path network policy did not close. The process is alive, it can still write to its volume, open a shell and resolve DNS, and the sandbox it sits in has more doors than the one you watched |
| Lock the pod in the kernel | Outbound connections, new processes and writes, for every container in the pod, without a restart | Reads, and the process itself. The task triage already handed to escalation continues under escalation‘s identity, and the work already on the queue waits for whoever picks it up |
Read the third column down. Not one row is empty, and the two that come closest, the gateway and the kernel, cut nothing the other three cut. Deleting the pod looks like the fastest switch and is the slowest to make stick, because everything that made the pod is still there. Revoking the key has the widest blast radius, because keys get shared. Deactivating the identity is the switch the industry is building this quarter, and by the vendors’ own description it governs the next login rather than the current one. The gateway and the kernel are the only two rows the agent had no hand in, which, as we argued in the safest place to run an AI agent, is the test: controls the agent can override are not controls.
Now translate the drill into the questions a team has to be able to answer before it needs to:
- Who can pull it, and from where? The NCSC asks for “named individuals or group responsible for agentic AI activities,” and Nadella’s brake belongs to “an authorized person.” Name them, and make the action one action, from the console or the command line, that does not require finding the agent’s author first.
- What does the agent do when it is refused? Retry, back off or try another route, depending on how it was written. Whoever wrote it knows which. Nobody else does until the drill.
- What happens to its callers and its queue? escalation is an agent too. If it retries triage forever, you have two incidents. If the queue replays the work when triage comes back, the stop was a pause.
- What proves the stop happened? An audit event for the apply and one for the lift, and a record of the refused calls, written by the thing that refused them rather than by the agent.
- What comes back when you lift it? The switch is also a decision about the normal state. If the agent returns to no restrictions at all, nobody will want to be the one who lifts it.
One agent makes these five questions an afternoon’s work and a runbook. Ten agents from three teams make them a spreadsheet of keys, owners and who shares what with whom. Two hundred agents, some calling each other and some sharing a key because it was in the Helm chart, make a switch per agent the only thing that scales, and the same switch for all of them the only thing anyone will remember at three in the morning.
What does a stop have to cut?
Lay the bill’s framework and the NCSC’s two cuts over the drill and each line becomes a requirement on the infrastructure rather than on the agent.
| The rule asks | With agents, that means | So the infrastructure must provide |
|---|---|---|
| “halt autonomous AI agent activity immediately” (NCSC) | Stop one agent’s calls without deleting it, redeploying it or asking it | A refusal at an enforcement point the agent does not control, on every call it makes and every call made to it, effective on the next request |
| “interrupt the communications between selected AI agents and the AI model inference infrastructure” (NCSC) | Cut one agent off from the model while two hundred others keep working | Per-agent identity on every request, so the refusal has a name on it, plus a kernel-level egress block for the routes that bypass the gateway |
| “Throttling or otherwise altering” the inference rate (H.R. 9917) | Slow a runaway agent, or a runaway bill, without stopping it | A token budget per provider and per time window, enforced before the call, that returns a refusal the agent can read |
| “Disabling or restricting a capability” (H.R. 9917) | Turn off one tool, for one agent, this morning | Policy that can see the tool and the operation, in effect on the next call without a redeploy |
| “Suspending” and “Terminate user access” (H.R. 9917) | Deal with the sessions already open and the tokens already issued | Tokens that expire in minutes, and a decision on every request rather than at login, so there is nothing long-lived to revoke |
| “Preserve the model weights and telemetry” (H.R. 9917); “log, audit and monitor” (NCSC) | Prove the stop happened, when, by whom, and what the agent did up to it | An audit event for the apply and the lift, and a record of every refused call, written by the enforcement point rather than narrated by the agent |
Read column three again. Nothing in it asks the agent to stop itself, and nothing in it is a redeploy. Every row is a control that sits outside the process, and two of them, the gateway and the kernel, are what the bill’s definition of an incident is really about: a switch the technology cannot subvert or conceal itself from is a switch wired somewhere the technology does not run. They are also two of the three layers Peter Kelly laid out in multi-layer policy for securing AI agents, with network policy as the third, and three layers earn their keep because each cuts a wire the others cannot see.
Now run the five switches through the table. Deleting the pod fails rows one and two, because the Deployment is the agent and the pod was never the thing to stop. Revoking the key fails row two, because it cuts every agent on that key, and row six, because a 401 from a provider is not your record of anything. Deactivating the identity fails row five on its own terms. The gateway satisfies rows one, two, four and six for every call it sees, and the kernel closes the routes it does not. Row three, the throttle, is the one most fleets have never wired at all, which is odd, because it is the only position on the bill’s dimmer that keeps the agent working.
What happens when it is done properly?
Here is what a governance layer like Tigera Lynx does for the table above, and what it leaves to you. Both halves matter.
Done properly, stopping a registered agent is one action, from the console or with one command, with no redeploy. The gateway refuses every call to the agent and every call from it, on the next request, with a 403 under a built-in policy that you cannot edit or delete and no custom policy can override, and because A2A, MCP and LLM traffic all pass the gateway, that one action cuts all three at once. On the node, the agent’s pods are locked in the kernel: no outbound connection, and a connection that was already open fails on its next send and is refused when the workload reconnects; no new process; no write to the filesystem; for every container in the pod and for processes already running, without restarting any of them. A workload the detector found but nobody registered gets the kernel half, which is the half that stops it reaching anything. Tokens the gateway issues live ten minutes by default and delegated tokens at most two, and every call is authorized again when it arrives, so there is no list of issued tokens to revoke; a stop at the gateway is a stop on the next request whatever the agent is holding. The dimmer’s other positions are there too: a token budget per provider, per second, minute or hour, refused with a 429 once spent, and a policy change that denies one tool or one operation for one agent, evaluated on the next call. Applying and lifting the stop each write an audit event, every refused call lands in the Agent Trail with the caller, the target, the decision and the policy that made it, and lifting the stop returns the workload to whatever sandbox policy was in force before, so the normal state is the one you chose, if you chose one.
Now the other half. None of that decides anything. A person pulls the switch, and who may is a role you assign: stopping an agent needs the administrator role, and who holds it at three in the morning is your rota to decide. A workload’s owner can opt one pod out of the kernel lockdown with an annotation, so who may set that annotation is a decision for before the drill rather than during it. The kernel half runs where the detector runs, on kernels 6.3 and newer, and a node below that enforces none of it, so the drill is also how you find out which nodes those are. The gateway half covers the traffic Lynx authorizes, so a route from the pod to a provider that bypasses the gateway is network policy you write first. The change lands on the next sync, so it is near immediate and not transactional, and the token budget is per provider and per gateway replica rather than per agent, so a runaway agent sharing a provider with a well-behaved one slows both. And the stop refuses what the agent would do next. It does nothing about the task already handed to another agent or the work already on a queue, and it will not tell you that the agent should have been stopped; that is still a verdict a person reaches with the evidence in front of them. What the infrastructure provides is the layer the word “switch” assumes exists: one action, at points the agent does not control, that stops its calls in both directions on the next request, and writes down that it did.
Put in properly, the stop is one action at 09:00, a refusal on every call by the next request, a pod that can no longer reach anything, and an audit event with a name on it. Put in badly, it is a kubectl delete and a Deployment that has replaced the pod before the prompt comes back.
Frequently asked questions
1.What is an AI agent kill switch?
A kill switch is a control that stops an AI agent without its cooperation and without redeploying it. For a model provider, the AI Kill Switch Act describes it as the capability to stop inference, terminate or suspend access, and shut the system down. For an organization running agents, the UK NCSC describes it as the ability to halt agent activity immediately, including restricting network access around the agents and cutting the path between an agent and the model. In practice it is several cuts rather than one: at the gateway the agent’s calls pass through, in the kernel on the node, and in the credentials it holds.
2.Does the AI Kill Switch Act apply to companies that run AI agents?
As introduced, no. H.R. 9917 covers entities that make a model available to third parties and earn at least $500,000,000 a year from it, where the model took more than $100,000,000 of compute to build. An enterprise running agents against someone else’s model is not a covered entity. If you serve models to third parties at anything near that scale, get a legal opinion on your own case; the bill’s definitions are to be updated by rule every year.
3.Is deleting the pod a kill switch?
No. A Deployment or StatefulSet controller exists to replace deleted pods, so deleting one buys seconds, and scaling to zero stops the pods and nothing else: the credentials are still valid, the callers are still retrying, and the queued work is still waiting. It is also the one switch in the drill that destroys the pod’s own evidence of what it was doing.
4.Does revoking an agent’s identity stop it?
It stops the agent getting new sessions and new tokens. Sessions already open and tokens already issued keep working until they expire, which is why identity vendors describe ending in-flight sessions as a separate capability. The shorter the tokens live and the more often each request is re-authorized, the smaller that gap, and a gateway that decides on every request closes it.
5.What is the difference between quarantining an agent and deleting it?
Quarantine leaves the agent in place and takes away what it can do: its calls are refused at the gateway in both directions, and its pods can no longer open connections, start processes or write to disk. The pod, its logs and its state stay for the investigation, and lifting the quarantine returns it to its normal policy. Deletion removes the pod and whatever it knew, and the controller that owns it brings back a fresh copy.
6.Who should be able to pull it?
A named person or group, as the NCSC asks, with the authority to act without first finding the agent’s owner. The team that built the agent should not be the only hand on it, because that team may be the reason it needs stopping, and it should not be an open permission, because a switch anyone can pull gets pulled by mistake. The same action should be available to the security on-call and the platform on-call, and both should have pulled it at least once outside an incident.
Whose question is it?
In the bill, the switch belongs to the company that serves the model, and the order to a Secretary. In the NCSC’s advice, it belongs to you, and to named individuals inside your organization. In Nadella’s version, to “an authorized person.” In the vendors’ versions, to whoever has the button. Four documents in five weeks, and all four agree on the hand that pulls it, if not on the wire.
Your fleet is not a model. It is two hundred Deployments that call models, and the switch that stops a model mid-task is not the switch that stops them. Every vendor will sell you a kill switch by the end of the quarter, so the morning-after question is what yours cuts, and what it leaves running.
So ask the question now, while it is cheap, and ask it of a named person. A switch with no name on it is pulled by whoever notices first, and as Would you notice? found, that is often somebody outside the building.
If you are an engineering/security leader or a head of platform, your question is about the fleet. If you ordered every agent stopped at 09:00, how many separate switches would that take, who holds each one, and at 09:05 how many agents would still be calling a model? The first number is how many ways your fleet was built. The last one is on next month’s invoice.
A kill switch nobody has pulled is a label on a box. Pull it on a Tuesday, and read what is still running at 09:01.
See Lynx in action
Tigera Lynx gives every AI agent, MCP server and LLM provider in your clusters a verifiable identity, a policy decision on every call, and a record written by the enforcement point rather than by the agent. Schedule a demo and see it on a live cluster.
Lynx is Tigera’s enterprise security and governance platform for AI agents on Kubernetes: identity, policy, detection, and audit for every agent in your cluster. Read How Lynx Works or request a demo.
