The AI Kill Switch Act Is a Dependency Test for Founders

On July 23, US Representatives Ted Lieu and Nathaniel Moran announced the AI Kill Switch Act, a bipartisan proposal that would require covered developers of the most powerful AI systems to retain the technical ability to throttle, suspend, or shut them down. The proposal also describes incident reporting, preservation of model weights and telemetry, user notification, compliance verification, and a graduated response that can include moving dependent operations to a backup system.

It is not law. The published draft still displays H. R. __ rather than an assigned bill number, its scope is aimed at very large developers and extremely expensive systems, and later committee or rulemaking work could change it. A typical small AI app company is unlikely to be a covered entity under the draft's current revenue and model-compute thresholds.

Founders should still pay attention. If your product depends on a covered model API, a provider's throttle, account suspension, capability restriction, regional isolation, or full shutdown becomes your customer incident. More importantly, the proposal turns “keep humans in control” into operational questions that any team can test today: Can you stop new actions without losing evidence? Can you keep a safe read-only path online? Can you revoke credentials independently of the model? Can you tell which customers and jobs were affected? Can you recover without replaying dangerous work?

This guide gives nontechnical founders and small product teams a reusable shutdown ladder, trigger matrix, dependency map, 60-minute exercise, evidence receipt, and 48-hour implementation checklist. It is product and operational guidance, not legal advice. It does not claim that the bill will pass or that a single off switch makes an AI product safe.

What the proposed Act actually says

Start with the 15-page draft bill, not the phrase “kill switch.” The current text would direct the Cybersecurity and Infrastructure Security Agency to maintain definitions for covered entities and covered technology through annual rulemaking. It describes a covered technology as an AI system whose development used compute that would cost more than $100 million at prevailing US cloud prices.

The draft's entity definition is conjunctive. A covered entity would operate the technology or a system incorporating it, make it available to a third party through an API, hosted service, or similar mechanism, and derive at least $500 million in gross revenue from that technology in the prior calendar year. The text exempts personal, academic, and non-commercial-only use and instructs rulemakers to consider burdens on small businesses.

For covered entities, the proposal would require technical capabilities to:

• stop inference;
• terminate user access;
• suspend an account, user, or use pattern associated with an incident, legal violation, or terms violation;
• shut down the technology;
• report a covered incident within 15 days of becoming aware of it.

If emergency authority were invoked, the draft would require preservation of model weights and telemetry, practicable notice to affected operators or users, confirmation that the order was executed, and verification through audit, telemetry, inspection, or forensic review. The sponsors' announcement summarizes these mechanisms, but the draft is the better source for thresholds and exceptions.

Three boundaries matter. First, this is a proposal, not an enacted requirement. Second, “covered incident” is defined around severe outcomes, concealment, interference with shutdown, and loss of control outside structured testing; it is not every hallucination or failed tool call. Third, already-downloaded open weights cannot be recalled by disabling one hosted API. Control depends on who owns inference, credentials, tools, compute, distribution, and downstream execution.

Why a bill for frontier developers matters to a small app team

The draft's direct obligations and your product obligations are different. Your startup may be far below its thresholds, yet still depend on a provider that can be throttled, restricted, or suspended. You may also have to pause your own workflow for incidents that never approach the bill's catastrophic-harm definition: duplicate invoices, incorrect account closures, data leakage, unsafe medical language, or an agent messaging the wrong customer.

Treat the proposal as a dependency test with three layers:

1. Provider control: What can the model or cloud provider throttle, disable, retain, or report?
2. Application control: What can your team stop at the job, tenant, tool, feature, model-route, and whole-product levels?
3. Business continuity: What useful service remains when generation or action execution is unavailable?

This is why the bill's most useful idea for builders is not “government gets a button.” It is graduated correction. A founder needs several independently controlled brakes, each matched to a defined failure and tested consequence.

Define six control terms before designing a switch

Teams often use stop, pause, disable, revoke, rollback, and recover as if they were interchangeable. They are not.

These terms should name observable system states, not intentions. “Agent paused” is ambiguous if its worker still completes queued emails. “Writes denied; queue frozen; active tool credentials revoked; read-only history available” can be tested.

One big red button is the wrong product model

A universal switch is simple to describe and dangerous to depend on. It may sit inside the same control plane that has failed, require credentials the incident responder cannot access, erase volatile evidence, cut off customer support, or stop a safe fallback along with the failing feature.

The better model is a ladder with independent enforcement points. The model should not decide whether the model may continue. A separate application policy, identity layer, job scheduler, provider console, or infrastructure control must be able to deny work even when the agent recommends proceeding.

The NIST Generative AI Profile recommends maintaining procedures for escalation when context-specific deactivation or disengagement criteria are met. NIST's current incident-response guidance also treats preparation, detection, response, and recovery as organization-wide work rather than one security-team action.

Your ladder should therefore satisfy four properties:

• Independent: responders can use it without asking the affected agent or relying on the same failed path.
• Scoped: it can stop the smallest trustworthy unit before escalating to a wider outage.
• Evidence-preserving: it freezes relevant traces, versions, approvals, tool results, and state transitions.
• Recoverable: it has a tested path to a safe prior model, reduced capability, manual workflow, or clean shutdown.

Use this six-level shutdown ladder

The following artifact translates the proposed Act's graduated response into a small-team product control. Adapt the thresholds and owners to your app.

The level is not a score of how frightening an output looks. It is a pre-agreed product state. If a customer-support agent recommends the wrong wording but cannot send, L0 or a normal correction may be enough. If it sends messages to the wrong accounts, L2 should be immediate. If tenant isolation cannot be trusted, escalate past L3 rather than pretending the blast radius is contained.

Do not require a perfect diagnosis before applying a reversible brake. The goal of early levels is to reduce exposure while preserving the ability to investigate.

Map every dependency the ladder must control

Create one row per consequential dependency. “Model: off” is not a complete inventory.

For every row, ask four uncomfortable questions:

1. Can the control be used when the primary admin is unavailable?
2. Does it stop already-authorized or queued work?
3. Can it be verified from the resulting state, not just a “success” banner?
4. Can recovery avoid executing the same side effect twice?

Set triggers before the incident

If the team decides severity while customers are being affected, confidence and commercial pressure will distort the decision. Define triggers with observable conditions and an owner.

Pair each trigger with a false-positive cost. Aggressive containment can itself cause harm: stopping a clinical workflow, losing a user's draft, blocking account recovery, or duplicating payments during failover. The draft bill explicitly calls out disruption to critical infrastructure, and the principle applies at smaller scale: a brake needs a safe stopping design.

The purpose is not to avoid ever shutting down. It is to know the trade-off in advance and choose the least harmful state that actually contains the risk.

A concrete scenario: an invoice-resolution agent

Consider a small SaaS company using an agent to resolve invoice discrepancies. It reads support tickets and account records, proposes a correction, asks a finance operator for approval, updates the billing platform, and emails the customer. The model comes from an external API; billing and email tools use separate OAuth credentials.

At 10:12, monitoring shows three approved corrections were applied to the wrong invoice IDs. One email also went to a contact from a different account. The team does not yet know whether the cause is a model update, retrieval error, stale approval, or tool mapping bug.

A weak response is to disable the model-provider key. That stops new generation but may leave approved tool jobs in the queue, retries in the billing connector, scheduled email sends, and already-cached proposals. It also destroys the team's ability to offer a safe read-only account summary if every feature shares that key.

The ladder response is:

1. Activate L2: the tool gateway denies billing writes and outbound email, independent of agent instructions. Read and draft functions remain available.
2. Freeze evidence: pin the model and prompt versions, preserve trace IDs, approval payloads, retrieved invoice IDs, tool parameters, queue state, and resulting billing records.
3. Apply L3: isolate the invoice-resolution workflow and its queue. Do not stop unrelated read-only help search unless evidence shows shared contamination.
4. Revoke and rotate: revoke write credentials only after recording identifiers and pending work; issue narrower credentials during recovery.
5. Reconcile: compare intended invoice, approved invoice, executed invoice, and email recipient for every in-flight job. Reverse only with finance authorization.
6. Move to L4: staff handle corrections manually while the app provides read-only evidence packs.
7. Recover in stages: replay sanitized cases with no writes, then use shadow mode, then allow one bounded write with dual approval before wider restoration.

Run this 60-minute founder exercise

You do not need a security department to learn whether the controls exist. Run a tabletop with the founder, product owner, someone who understands integrations, and the person who handles customers.

Do not grade the exercise on how quickly someone clicks a toggle. Grade it on containment accuracy, evidence completeness, customer continuity, and whether the team can prove the final state.

Keep a shutdown receipt

The proposed Act's preservation, notification, confirmation, and verification concepts point to a useful artifact for any product: one receipt for every material control action.

incident_id: inc_2026_07_26_001
declared_at: 2026-07-26T01:12:00Z
trigger:
  signal: unauthorized_cross_account_send
  evidence_ids: [trace_8f2, message_193]
decision:
  ladder_level: L2
  scope: invoice_resolution_write_tools
  owner: incident_lead
  reason: "Contain external side effects while scope is unknown"
controls:
  - control: tool_gateway_deny
    target: [billing.write, email.send]
    executed_at: 2026-07-26T01:14:20Z
    verification: deny_test_77
  - control: queue_freeze
    target: invoice_resolution
    executed_at: 2026-07-26T01:15:03Z
    verification: queue_snapshot_42
customer_effect:
  new_jobs: draft_only
  affected_accounts: 3
evidence_hold:
  versions: [model_route_12, prompt_31, tool_policy_9]
  state_snapshot: snapshot_2026_07_26_0116
recovery_gate:
  required_tests: [tenant_targeting, approval_binding, retry_deduplication]
  approvers: [product_owner, finance_owner]

Store identifiers and hashes where the underlying content is sensitive. The receipt should link to protected logs, not become a new leak. Record failed control attempts too; they are part of the incident.

This structure also supports regulatory or contractual review. The EU AI Act, for example, requires post-market monitoring for covered high-risk systems and sets serious-incident reporting duties in Articles 72 and 73. Those obligations have different scope and timelines from the US proposal. The practical commonality is that a team needs preserved, attributable evidence before it can investigate, notify, or prove a corrective action.

Failure modes that make a kill switch theatrical

Major developers already describe layered approaches rather than magical buttons. OpenAI's Frontier Governance Framework covers risk assessment, mitigations, incident response, security, and ongoing updates. Google DeepMind's Frontier Safety Framework update describes deployment mitigations, safety cases, governance review, and post-deployment reassessment. Anthropic's Advanced AI Framework proposes testing, external evaluation, ongoing disclosure, incident handling, and government accountability. These are developer positions, not independent proof that every control works; they nevertheless reinforce that shutdown capability belongs inside a wider operating system.

What the proposal does not settle

The bill leaves important questions to later rulemaking or political debate: how compute cost is measured, how capability and open-weight distribution affect coverage, how cross-border or multi-cloud orders work, how shutdown standards are verified before an incident, and how to avoid harmful interruption of dependent services. Its text can change, stall, or fail.

It also targets catastrophic frontier-system risk. Most YBuild readers face more ordinary but still material product incidents. Do not claim compliance with a future law because you added a feature flag, and do not force every low-risk AI feature through a catastrophe protocol.

A shutdown ladder is most useful when an AI system can create external side effects, access sensitive data, act across tenants, persist memory, run for a long time, or create a hard vendor dependency. A read-only brainstorming tool with no sensitive context may only need ordinary availability and privacy controls. A deterministic workflow may be safer without an agent at all.

Finally, a brake does not repair weak authorization. It does not replace least privilege, approval integrity, output validation, tenant isolation, evaluation, or secure software delivery. The July OpenAI/Hugging Face evaluation incident is a current reminder that boundaries can chain together in unexpected ways; the parties' OpenAI account and Hugging Face disclosure should be read as an evolving incident record, not as evidence that every production AI system will resist shutdown.

A 48-hour checklist for founders

Within the next two days:

• name one incident lead and one backup who can activate controls;
• list every model, queue, tool, credential, schedule, memory store, webhook, and customer channel used by one consequential AI workflow;
• define L0 through L5 in observable product states;
• verify that write-capable tools can be denied outside the model;
• decide what happens to active, queued, scheduled, and approval-waiting work;
• separate read and write credentials where the platform permits it;
• write five triggers, the default level, decision owner, and maximum response time;
• implement or verify a safe read-only, earlier-model, deterministic, or manual fallback;
• create the shutdown-receipt template and protect its linked evidence;
• run one 60-minute scenario and record missing controls;
• require reconciliation, negative tests, staged exposure, and named approval before restart;
• ask critical vendors what they can throttle, isolate, preserve, notify, and restore—and what remains your responsibility.

References

1. US House draft, AI Kill Switch Act
2. Representative Ted Lieu, announcement of the AI Kill Switch Act
3. NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
4. NIST, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
5. European Union, Artificial Intelligence Act, Articles 72–73
6. OWASP, AI Agent Security Cheat Sheet
7. OpenAI, Frontier Governance Framework
8. Google DeepMind, Updating the Frontier Safety Framework
9. Anthropic, Advanced AI Framework
10. OpenAI, model-evaluation security incident with Hugging Face
11. Hugging Face, security incident disclosure — July 2026