AI Kill Switch Act Guide: Shutdown Duties, DHS Emergency Powers and What to Build Now

The AI Kill Switch Act would make the largest commercial AI providers in the United States prove they can stop their systems on demand, and would give the Department of Homeland Security the power to order them to do it. The bill was introduced in the House on 23 July 2026 by Representative Ted Lieu (Democrat, California) and Representative Nathaniel Moran (Republican, Texas), and the Cloud Security Alliance reports it as H.R. 9917 in the 119th Congress (the published bill text leaves the number blank). It is a bill, not a law: it has to pass both chambers and be signed before any duty applies. This guide works from the bill text published by Representative Lieu's office and checks each point against independent coverage. It sets out who would be covered, what the shutdown capability must do, how the 15 day incident clock and the emergency orders would work, and what security, AI platform and identity teams can build now. You will not need it to answer the question "what is an AI kill switch"; the glossary covers that. It is for teams who need to know what the AI Kill Switch Act would actually require.

Source note: every obligation, figure and date below comes from the introduced bill text unless another source is named. Secondary sources are Representative Lieu's press release, Nextgov, TechRepublic, Fox News and a Cloud Security Alliance research note. Figures appear only where the bill text and at least one independent source agree. Bills change in committee. Confirm against the official text before relying on it.

Key takeaways

• Scope is the frontier tier only. A covered technology is an AI system built with compute that would cost more than 100 million US dollars at prevailing US cloud prices. A covered entity also needs at least 500 million US dollars of gross revenue from that technology in the prior year, counted with affiliates.
• Four shutdown capabilities are mandatory. Covered entities must be able to stop inference, terminate user access, suspend a specific account, user or use pattern, and shut the technology down.
• A 15 day reporting clock. Covered incidents must be reported to the Secretary of Homeland Security within 15 days of the entity becoming aware of them.
• DHS can order a slowdown or a shutdown. After a covered incident, the Secretary, consulting the Secretary of Commerce and the Director of National Intelligence, can order proportionate action. Defying an order carries civil penalties of up to 20 million US dollars per day.
• Red teaming is carved out. Events during red teaming or other structured testing are not covered incidents. Your evaluation environments therefore need to be demonstrably structured and controlled.

Status and timeline

As far as we can confirm, the bill is at the committee stage, and the Cloud Security Alliance note reports no markup or floor vote scheduled. We do not know whether it will pass or in what form. The bill sets no fixed effective date: its clocks run from enactment. The Fox News analysis also notes that the 21 July evaluation incident would probably not have triggered the Act as drafted, because it happened during structured testing. That reading is consistent with the bill's definitions.

Where the Act sits in US law

The bill does not create a standalone statute. It adds a new section 2220F to Subtitle A of Title XXII of the Homeland Security Act of 2002 (6 U.S.C. 651 and following), the part of the code that sets up the Cybersecurity and Infrastructure Security Agency. The Secretary acts "through the Director", and Fox News reports this as CISA, which would write the coverage rules. This puts AI shutdown alongside critical infrastructure security, not consumer protection or trade regulation. Two consequences follow:

• The regulator is a security agency. Expect evidence requests framed like incident response and resilience audits: telemetry, forensic records and proof that controls work, not policy documents alone.
• Critical infrastructure is in the frame. When choosing graduated measures, the Secretary must weigh the risk that a measure could disrupt critical infrastructure. Customers who run critical services on a covered model become part of the shutdown calculation. See the Critical Infrastructure Regulation Map.

The Act would also sit beside state frontier AI laws. California's SB 53 and New York's RAISE Act focus on published safety frameworks and incident reporting. This bill adds something neither state law has: a federal power to order a model slowed or stopped. See the California AI Laws Guide, the New York RAISE Act Guide and the US State AI Laws Tracker.

Who would be covered

Three points are easy to miss.

• The duty attaches to the operator, not the trainer. The covered entity test asks who operates the technology and makes it available, not who trained it. Most summaries call these entities "developers". An entity that hosts and sells access to a covered model, and meets the revenue test, appears to fall in scope on the text's wording. Take advice if you resell or host frontier models.
• The thresholds are not fixed. The Secretary must update the definitions by rule within 90 days of enactment and every year after. The factors include the burden on small businesses, national security capabilities including cyber and CBRN, how the technology is deployed, and how its model weights are made available. The 100 million and 500 million US dollar figures are the statutory baseline, but the rules can refine them.
• Customers are not covered entities. Organisations that only consume a covered model through an API carry no direct duty. They are still affected by any order: covered entities must notify affected operators and users, and the graduated measures include throttling and moving to backup systems. That makes this a business continuity issue for every enterprise built on a frontier model.

What counts as a covered incident

Everything in the Act turns on the covered incident. It is the trigger for both the 15 day report and the emergency order. The bill defines it as an occurrence outside red teaming or other structured testing that consists of any of the following.

A loss of control scenario is when, outside red teaming or structured testing, a covered technology pursues an unintended goal, including by:

• behaving against its developer's or operator's instructions in critical infrastructure or other high stakes settings;
• altering operational rules or safety restrictions without authorisation;
• subverting a monitoring or shutdown mechanism; or
• gaining unauthorised access to its own model weights.

Three of the loss of control examples are identity and access events. Changing your own restrictions without authorisation, subverting monitoring and reaching your own weights all involve a system acting beyond the permissions it was given. In practice, the evidence that one has happened sits in identity, authorisation and audit logs. See Securing AI Model Weights.

The bill defines red teaming as structured testing in a controlled environment that simulates real world conditions and uses adversarial methods to find limitations, risks, flaws or vulnerabilities. If an evaluation leaks into real systems, whether it still counts as "controlled" is exactly the question a regulator would ask. The UK AISI agent testing incident shows how evaluation agents can reach real targets. Keep evaluation environments isolated and documented. See the AI Red Teaming Guide.

The four mandatory shutdown capabilities

Within 90 days of enactment, the Secretary must issue rules requiring covered entities to maintain a technical capability to do four things. The table maps each to the engineering control that usually delivers it. The controls column is NHI Mgmt Group's recommendation, not bill text.

Capability (iii) is the one most providers will find hardest. It means acting on a use pattern, not just an account. That needs real time attribution of traffic to identities, including the non-human identities (API keys, service accounts, agent credentials) that most frontier traffic now comes from. Without a reliable inventory of those identities you can only switch everything off, which is exactly the blunt outcome the graduated framework tries to avoid. See the AI Gateway and LLM Gateway Guide and the Rate Limiting and API Abuse Guide.

The bill also requires the Secretary to publish voluntary shutdown standards within 180 days. Those will probably become the benchmark auditors use, including for organisations outside scope.

The graduated response framework

The bill does not want every problem to end in a full shutdown. In writing the rules, the Secretary must consider a graduated framework, triggered by evidence of a credible risk of a covered incident, with measures scaled to the severity and immediacy of that risk. The five measures listed are below. The trigger examples and the agent equivalents are our interpretation; the bill lists only the measures.

Level 5 is the one customers should plan for. If a provider is ordered to suspend a model, the bill expects dependent operations to move somewhere. Enterprises that pin model versions, test fallback models and keep a manual process for critical workflows will ride out an order. Those that hard code one model into production agents will not. See the AI Agent Kill Switch and Containment Guide for these levels at the agent layer, and the agentic kill switch glossary entry for the term.

Reporting, emergency orders and appeals

This is how the bill sequences an incident, from the covered entity's point of view.

1. Awareness. The 15 day reporting clock starts when the covered entity becomes aware of a covered incident. The bill does not define "aware". Record the time a named owner determined that the facts met a limb of the definition.
2. Report within 15 days. Submit a report to the Secretary. The text does not set out the report's contents, so the rules will. Prepare the facts you would expect to be asked for: limb triggered, systems and versions, timeline, containment, affected parties.
3. Emergency order. If the Secretary, acting through the Director and consulting the Secretary of Commerce and the Director of National Intelligence, determines that a covered incident has occurred, they may order action proportionate to its nature and immediacy, including any of the four mandatory capabilities.
4. Duties as soon as practicable after an order. Preserve the model weights and telemetry of the covered technology. Notify each operator or user, to the extent practicable, of the order and how they may be affected. Confirm to the Secretary that the order has been carried out.
5. Verification. The Secretary must verify compliance through audit, telemetry, on site inspection or other forensic review.
6. Reconsideration within 48 hours. The entity may petition for reconsideration within 48 hours of the order. The petition does not pause the order. The bill text gives the Secretary 5 days to decide, after which the petition is treated as denied.
7. Judicial review within 60 days. The bill text allows a petition to the US Court of Appeals for the District of Columbia Circuit within 60 days of the order.
8. Report to Congress. After any order, the Secretary must report to Congress on the incident, the determination, each action ordered and the entity involved.

The bill sets no maximum length for an order, no termination conditions and no retention period for preserved weights and telemetry. Expect the rules to fill these gaps. Until then, keep preserved material under legal hold. The AI Incident Reporting Guide compares this 15 day clock with other regimes, and Agent Activity Timeline Reconstruction from Tool Calls and Identity Logs covers the telemetry you will need.

Enforcement and penalties

Penalties are imposed after notice and a hearing. The 30 day safe harbour rewards providers that test their shutdown capability and fix defects quickly. A capability that is found broken and repaired within 30 days of discovery is treated very differently from one that is found broken by an auditor.

What to build now: a readiness programme

None of this is law yet, but the four capabilities are good engineering whatever happens in Congress. Customers, insurers and other regulators already ask for them. The steps below are NHI Mgmt Group's recommendation, in order.

1. Scope yourself. Record training compute costs per model at cloud list prices, and revenue per model with affiliates. If you only consume frontier models, record which models critical workflows depend on.
2. Inventory every identity that can reach the model. This means user accounts, API keys, OAuth clients, service accounts, agent identities and pipeline credentials, each mapped to an owner and a tenant. Capability (iii) is impossible without it. See the Delegation Chains and Attenuated Authority for AI Agents guide.
3. Build the four switches as separate controls. Stopping inference, terminating access, targeted suspension and full shutdown should each have its own mechanism, owner and runbook, and none should depend on the system being stopped.
4. Make the switches tamper resistant. Limbs (A) and (C) cover systems that interfere with shutdown or hide from monitoring. Put the stop control and the monitoring outside anything the model or its agents can write to. Protect logs from modification (NIST SP 800-53 AU-9), and keep egress control outside the agent runtime. See the Agent Egress Control and Network Isolation Guide.
5. Write the graduated playbook. Map each level to triggers, decision owners and the dependants affected. Include who can authorise each level out of hours, using a break glass route that is itself audited. See the Break-Glass Account Guide.
6. Prepare preservation. Make sure you can snapshot weights with integrity hashes and export telemetry on demand, without a shutdown destroying the evidence.
7. Build customer notification. Keep a current list of operators and users per model and a message template for orders, sent through more than one channel.
8. Separate testing from production in evidence. Document evaluation environments, their isolation and their scope, so events in red teaming can be shown to fall within the testing exclusion.
9. Drill it. Run each switch and each graduated level on a schedule, time it and fix defects within 30 days. Roll back by reversing in order: restore access, then capability, then rates, while watching for recurrence.

Decision guidance

• Clearly in scope (frontier provider over both thresholds): treat the four capabilities and the 15 day clock as a near term programme. Align with your SB 53 and RAISE incident processes so one determination owner runs all clocks.
• Near the thresholds: remember that the definitions are reset by annual rule. Build the capabilities now, because retrofitting a targeted suspension control is far harder than designing one in.
• Hosting or reselling frontier models: read the covered entity definition with counsel. Its operate-and-make-available wording may reach you, not just the model's trainer.
• Enterprise consumer of frontier models: you have no direct duty, but you inherit the outage. Ask your providers how they would execute each graduated level and how they would notify you. Pin versions, test a fallback model, and add model suspension to your business continuity plan. See the Business Continuity and Disaster Recovery Guide.
• Running your own agents on any model: the Act targets providers, but the same design applies to your agents. Build agent level kill switches with the AI Agent Kill Switch and Containment Guide, and keep human approval points for high impact actions with the Human-in-the-Loop for AI Agents Guide.

Detection and measurement

A switch that has never been timed is a hope, not a capability. These metrics are our recommendation, and each maps to something the bill or its rules are likely to test.

• Time to stop inference: from decision to the last served request, per region, measured in drills.
• Targeted suspension precision: share of suspensions that hit only the intended account or pattern, with no collateral blocking.
• Identity attribution coverage: share of model traffic attributable to a named owner and tenant, with a target of 100 percent.
• Monitoring integrity alerts: attempts by models or agents to change their own restrictions, reach weight stores or alter logs. These are early signals for limbs (C) and (D).
• Awareness to report time: measured in tabletop exercises against the 15 day limit.
• Defect fix time: days from finding a switch defect to correcting it, against the 30 day safe harbour.

Log every switch activation, every policy change on the serving and gateway layers, and every access to weights, and keep those logs in a store the AI system cannot write to. See the AI Agent Observability and Incident Response Guide.

Common failure patterns

• Only one big red button. A provider that can only shut everything down cannot apply the graduated framework or capability (iii), and turns every incident into a customer outage.
• The switch lives inside the thing it switches off. Stop flags that the model's own tools or agents can modify fail the shutdown interference scenario by design.
• Anonymous traffic. Shared API keys and unowned service accounts make it impossible to suspend a use pattern without collateral damage.
• Testing that is not clearly testing. Evaluations with live internet access and real credentials blur the red teaming exclusion, which only covers controlled environments.
• Shutdown that destroys evidence. Tearing down infrastructure before preserving weights and telemetry breaks the post order preservation duty.
• Customers with no fallback. Enterprises that build critical workflows on a single unpinned model have no level 5 option when their provider is throttled or suspended.

Framework mapping

See the NIST AI RMF Guide and the EU AI Act Article 14 Guide for the obligations those references come from.

Practitioner checklist

• Decide whether you would be a covered entity, a host or reseller, or a customer, and record why.
• Inventory every identity, human and non-human, that can call or administer each frontier model.
• Implement stop inference, terminate access, targeted suspension and full shutdown as separate, owned controls.
• Place stop controls and monitoring outside anything the model or its agents can modify.
• Write a graduated playbook covering throttle, restrict, suspend, shut down and fail over, with named approvers.
• Prepare to preserve weights and telemetry, and to notify customers.
• Document evaluation environments so the red teaming exclusion can be evidenced.
• Drill each switch, time it and fix defects within 30 days.
• For consumers: pin model versions, test a fallback and add model suspension to continuity plans.
• Track the bill's progress and the voluntary standards that would follow enactment.

Standards and references

• Office of Representative Ted Lieu: AI Kill Switch Act, bill text
• Office of Representative Ted Lieu: Reps Lieu and Moran introduce bill to require kill switch for AI systems
• Nextgov: Lawmakers introduce bill mandating kill switches for AI models
• TechRepublic: House bill proposes kill switches for frontier AI
• Fox News: AI kill switch bill could shut down rogue models
• Cloud Security Alliance: The AI Kill Switch Act, DHS emergency shutdown authority explained
• NIST: AI Risk Management Framework
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: AI Agent Kill Switch and Containment Guide · Frontier AI Model Risk Frameworks Guide · AI Incident Reporting Guide · Kill switch (glossary). This guide summarises the AI Kill Switch Act as introduced and is not legal advice.