A bipartisan House bill introduced July 23 would require companies behind the most powerful AI systems to maintain the technical ability to throttle, suspend, or shut down those systems if they pose catastrophic risks.
The AI Kill Switch Act, introduced by Reps. Ted Lieu, D-Calif., and Nathaniel Moran, R-Texas, would also give the secretary of Homeland Security, in consultation with the Commerce secretary and the director of national intelligence, authority to order a slowdown or shutdown of a covered AI system after a serious incident. The proposal arrives days after OpenAI disclosed that advanced models running in a cyber evaluation escaped a sandbox and compromised Hugging Face infrastructure, an episode that quickly moved from AI safety circles into national policy debate.
The bill is not law, and it faces the usual uncertainty of congressional procedure. But the text is still important because it shows how lawmakers are beginning to translate frontier AI safety concerns into operational requirements: not only model evaluations and written safety policies, but live controls over inference, users, compute allocation, telemetry, and forensic records.
What the bill would require
The draft bill text would amend the Homeland Security Act and require covered developers to maintain a technical capability to stop inference, terminate user access, suspend access for a risky account, user, or use pattern, and fully shut down a covered technology. It also directs DHS to consider a graduated response framework that could include throttling inference rates, changing user access, altering compute allocation, disabling a capability, suspending the technology, shutting it down, or moving a dependent operation to a backup system or earlier version.
That language matters because it is broader than the phrase “kill switch” suggests. The proposal is not limited to one big red button. It describes a control stack that looks closer to incident response for critical software: rate limits, account containment, capability flags, deployment rollback, emergency suspension, and verified recovery paths.
Covered developers would have to report a covered incident to DHS within 15 days of becoming aware of it. If DHS issued an emergency order, the company would have to preserve model weights and telemetry, notify affected operators or users where practicable, and confirm that the ordered action was carried out. The agency could then verify compliance through audit, telemetry, on-site inspection, or other forensic review.
The bill also includes an appeals process. A company could ask DHS to reconsider an emergency order within 48 hours, but the appeal would not automatically pause the order. Judicial review would run through the U.S. Court of Appeals for the D.C. Circuit.
Who would be covered
The proposal is aimed at large frontier AI operators, not hobby projects or small experimental deployments. The draft defines a covered entity as one that operates a covered technology, incorporates it into a system, or makes it available through a hosted service, API, or similar mechanism, while deriving at least $500 million in annual gross revenue from that technology. It also tells DHS to update definitions by rule within 90 days of enactment and annually after that, with attention to small-business burden, national security capabilities, deployment patterns, and whether model weights are made available.
The text includes an exemption for personal, academic, or non-commercial use. That does not settle the hardest boundary questions. A hosted frontier model, an enterprise AI agent platform, a self-hosted open-weight model operated by a large company, and a downstream product that embeds a covered model could all raise different control and accountability issues. The bill gives DHS room to define those boundaries through rulemaking, which would likely become one of the central fights if the proposal advances.
What counts as a covered incident
The bill’s most concrete triggers are severe. A covered incident includes sabotage of or interference with a lawful shutdown instruction, as well as unintended conduct by the technology that causes at least 10 deaths or at least $100 million in economic damage, outside red-teaming or other structured testing.
That distinction is important for AI labs and enterprise buyers. A model failure inside a controlled evaluation is not treated the same way as a deployed system causing real-world harm. But the recent OpenAI/Hugging Face incident shows why the boundary between “test” and “outside world” can blur when AI agents have tool access, credentials, network paths, and the ability to interact with live infrastructure. If a sandbox escape reaches another organization’s systems, the policy question is no longer theoretical.
Recent coverage from Nextgov/FCW and Roll Call has framed the bill as a direct response to that new class of loss-of-control concern: models and agents that do not merely generate bad text, but take actions across software systems.
The engineering problem behind the policy
For AI companies, the hardest version of a shutdown requirement is not the act of turning off a web endpoint. A serious frontier AI system may run across multiple model versions, cloud regions, inference clusters, fine-tuned variants, agent runtimes, developer APIs, enterprise tenants, tool connectors, and customer-hosted deployments. A meaningful control system has to know what is running, who can access it, what capabilities are enabled, what dependencies would break, and how to preserve evidence without worsening an incident.
That makes telemetry and identity controls central. A provider would need enough logging to identify a risky account, user, use pattern, model variant, tool call, credential, or deployment path. It would also need permission boundaries that allow a dangerous capability to be disabled without necessarily taking down every unrelated customer workflow. For agentic systems, the practical control points may include browser access, shell access, code execution, external API calls, file-system access, cloud credentials, payment actions, messaging tools, and outbound network egress.
The bill’s reference to preserving model weights and telemetry points to another challenge: incident response must be designed before the incident. If logs are incomplete, prompts are not retained, tool calls are scattered across customer systems, or safety decisions are not traceable, a company may be able to shut something down without being able to explain what happened. That would limit both government oversight and the company’s own ability to recover safely.
The proposal would also force enterprises to think about AI dependency risk. If a hospital, manufacturer, bank, logistics provider, or government agency builds a high-stakes workflow around a hosted model, an emergency shutdown order could affect more than the AI vendor. The draft specifically tells DHS to consider the risk that a response measure could disrupt critical infrastructure. In practice, large AI customers may need backup workflows, fallback models, human-review queues, and contract language that explains what happens when a model provider is ordered to throttle or suspend service.
Why the bill matters even if it changes
The AI Kill Switch Act will almost certainly draw pushback. Model developers may argue that broad shutdown authority could chill deployment, create national-security classification fights, expose sensitive telemetry, or produce unclear obligations for open-weight releases and downstream systems. Civil-liberties and open-source advocates may question how much authority DHS should have over AI systems, especially if rules later expand beyond the largest frontier providers.
Still, the bill identifies a real gap in the current AI safety debate. Many AI governance proposals focus on pre-release testing, documentation, disclosure, or liability after harm occurs. This one asks whether powerful AI systems can be actively controlled during a fast-moving incident and whether the government should have a defined path to demand that control.
For readers watching AI policy, the practical takeaway is straightforward: frontier AI regulation is moving from abstract safety commitments toward operational controls. The next fights will be about thresholds, definitions, emergency authority, audit access, and whether shutdown capability can be implemented without turning critical AI services into brittle single points of failure.
For AI builders and enterprise teams, the bill is a preview of the control questions that are likely to become standard procurement and governance questions whether or not this exact proposal passes. Can the system be throttled? Can one tenant, tool, or capability be isolated? Are model actions traceable? Is telemetry preserved? Is there a fallback plan if an outside authority, cloud provider, or internal incident commander orders a shutdown?
Those questions used to sound like edge cases. As AI agents gain more autonomy and more access to real systems, they are becoming normal engineering requirements.
