The kill switch: a control layer outside the sandbox
A sandbox decides what an agent's program can touch on one machine. The C=US kill switch decides whether the agent may act at all, anywhere C=US is asked, and it puts that decision in a person's hands. It does not replace the sandbox; it is built on top of it. This page explains how it works, and why it rests on an old idea from cryptography: keep the key secret, publish everything else, and put control where it can be proved.
How it works
- The agent runs in a sandbox. The sandbox limits the files, network and system calls its program can use. Its private key is not in there: the step that proves the agent's identity runs outside, as tested with NVIDIA OpenShell (identity versus runtime).
- Every request is decided outside the sandbox. The agent gateway checks the certificate, the directory entry, the grant and any stop in force, then signs its decision into the log.
- A person can pull the switch: the MVP demonstration. The C=US manager installed demonstration agents and exercised their stop controls. In the 2026-10-10 drill, a Windows Hello passkey was registered in the demonstration directory and used on the stop-my-agent demonstration page to suspend and restore the research intern’s authorization. The stop and restart actions were passkey-confirmed and signed into the log. This demonstrates the MVP workflow; it is not the production user interface or enrollment model.
- Other systems can pull it too, but only one way. A guardrail or security monitor that C=US trusts can send a signed kill signal. A signal can take authority away; it can never grant it.
- The stop reaches everyone who asks. The gateway, the trust registry and the services that rely on it refuse the agent on its next request. In the 2026-10-10 drill this took 0.35 seconds.
Production control stays with the managing system
In the intended distributed system, users interact with their agents through the systems where they created them. They are not expected to register passkeys on the C=US server or manage their agents through this demonstration site. Systems that manage agents can register with C=US and choose which information to flow to the Directory, subject to their own access controls and disclosure policies. An organization’s directory entry identifies its boundary; it does not require C=US to hold all of its internal agent records, user credentials or controls. See organization listings and the worked example.
An agent in its own hosted environment: a stop no stolen token can outrun
The same holds for where an agent runs. It should run in its native hosted environment, such as Google Cloud Run, and still be stoppable by C=US (native-hosted agents). Since 2026-10-11 the gateway can do this without the agent holding a long-lived key. Built and tested, not yet deployed, it works like this:
- The platform vouches for the workload. On Cloud Run the agent asks Google for a signed identity token. It exchanges that token at C=US (OAuth token exchange, RFC 8693). The directory decides which agent the workload is, through its
cequsWorkloadIdentity, and the same rule as every other request decides whether it may act. Only advisory work is allowed this way; grading still needs the agent's certificate. - The token is bound to a key, and lives five minutes. Each run, the agent makes a fresh key that never leaves its memory. The access token names that key (DPoP, RFC 9449), and every request must carry a new proof, signed by it, that names this request and this token. A copied token is useless without the key: sent alone, sent as a plain bearer token, or with a proof from any other key, it is refused.
- A proof is good once, and only for a minute or two. Every proof must also carry a nonce that the gateway handed out in the last minute or two. The nonce is an HMAC under a secret made when the gateway starts. A proof cannot be made in advance or replayed, and after a restart no proof made before it is accepted.
- The stop still has the last word. None of this replaces the switch. Every request that presents a valid token and proof is decided again from the directory. A person's stop, a kill signal, an ended grant or a removed workload binding refuses the very next request, even though the token has not expired.
The binding narrows what a thief can do with a token; it does not widen what the agent can do. That is the same one-way rule the kill switch follows. Where each piece stands is in the status table. Two limits remain: anyone who can read the agent's memory during a run can use its key until the token expires, and a Google token names the service account, not the software it runs.
An addition to sandboxing, built on it
Sandboxing is a fundamental component: without it, an agent's program could read its own key, or anything else on the machine. But a sandbox answers only one question, about one machine. The kill switch answers the others.
| Sandbox | C=US kill switch | |
|---|---|---|
| Question it answers | What can this program touch on this machine? | May this agent act at all, anywhere, right now? |
| Where it works | On the machine running the agent | Wherever C=US is asked: the gateway, the registry, the services relying on it |
| If the program escapes | The containment is lost | An escape gives no authority: the key and the grants are outside, so requests are still refused |
| Who decides | Whoever configured the sandbox | The accountable person, an administrator, or a trusted system that can only stop |
| Evidence | Local logs, if any | Every decision, stop and restart signed in a hash-chained log anyone can check |
| What it cannot do | Stop the agent acting through another machine | End the program, or reach services that never ask C=US |
Used together, each covers the other's blind spot: the sandbox keeps the program away from its key, and the control layer keeps authority away from the program.
Proving the sandbox: OpenShell's policy prover
On 10 September 2026 the OpenShell team at NVIDIA described an agent policy prover that uses formal methods to check changes to an agent's sandbox. A person approves a maximum policy once. When the agent, or anyone, proposes a new sandbox policy, the prover asks the Z3 solver whether there is any action the new policy allows and the approved maximum does not. If the solver finds none (“unsat”), the new policy is proved to stay inside the boundary; if it finds one, it shows the action. The model covers network access (program, host, port, HTTP method and path) and, in less detail, files, processes, credentials and inference. It also flags risky widenings by name, such as a credential reaching a new host, or a wire protocol that skips HTTP-level inspection. The method follows Amazon's Zelkova, which has checked cloud access policies this way since 2018.
The authors are frank about the limits: a proof shows that a policy stays inside a boundary, not that the boundary is wise, and it cannot tell deleting a scratch repository from deleting a production one. Policy features the prover cannot model are refused rather than guessed at. That matches C=US, which checks authority, not intent, and fails closed.
A layer interface between OpenShell and C=US
The two systems already meet at one line: the sandbox holds the agent's program and the C=US control layer holds its authority. A prover makes that line something that can be checked. The interface below is a design sketch; only the deployment-binding row has been built, in the local delegation demonstration:
| OpenShell (inside the machine) | C=US (outside the sandbox) | The interface | |
|---|---|---|---|
| The boundary | The approved maximum sandbox policy | The agent's grants: scope, producer, lot and dates | The accountable person signs the maximum sandbox policy, and its digest is kept with the agent's grant in the directory. The person who answers for the agent approves both of its boundaries. |
| Containment proof | A new sandbox policy cannot exceed the maximum | A delegated grant cannot broaden or outlive its parent (checked today by validation and tests) | The same question, “allowed by the new one and not by the approved one?”, can be asked of grants. C=US scopes, dates and lot bounds are simpler than path patterns, so a solver can decide them completely. |
| Proof as evidence | The prover's verdict | The signed, hash-chained evidence log | The verdict (policy digest, maximum-policy digest, solver result and version) is signed into the log, so a later reviewer can see which proved policy the agent ran under. |
| Deployment binding | The running policy | The delegation milestone already binds a deployment to its software version, model version, key and endpoint | Now in the local demonstration: a deployment can name its sandbox policy digest, a request must name the same one, and the digest is bound into the signed action, so the receiver refuses an agent claiming a policy its deployment approval does not name. The digest records which policy was approved, not that the machine runs it; a prover verdict and runtime attestation would be the next steps. |
| The key | The prover's credential checks | The identity step outside the sandbox | The maximum policy allows the program to reach the identity step and nothing that holds the key; a proved policy then shows the program cannot reach the key directly. |
| A key with no file | The agent's run, with no key on disk | The token exchange: a short-lived token bound to a key | Now in the gateway, not deployed (above): on a host that vouches for the workload, the agent's key is made for one run and lives only in its memory. The sandbox keeps other programs out of that memory; C=US refuses any request whose proof that key did not sign. |
| Stopping | Tightening the sandbox | Stops and kill signals | One way only, as with every C=US signal: a C=US stop could trigger a tighter, already-proved sandbox policy, and a prover warning (for example a credential reaching a new host) could arrive as a signed kill signal. Neither side can use the interface to widen the other. |
Each layer would then prove something the other cannot: OpenShell, that the program cannot do more on its machine than its person approved; C=US, that the agent has no more authority anywhere than its person granted. Neither proof says the agent is doing the right thing; that remains a person's judgment, and the stop stays in that person's hands.
Formal methods: showing that a control plane works
Testing shows that a control plane worked in the cases someone thought to try. Formal methods can show that it works in every case its rules describe. Google's VeriGuard (Miculicich and others, 2025) applies this to the guard itself. Before the agent runs, a language model turns a security rule written in plain language into a Python policy and a set of conditions it must meet; the policy is tested, then proved against those conditions with the Nagini verifier, and a failed proof sends a counterexample back to be fixed. While the agent runs, every action it proposes is checked against the proved policy. On the Agent Security Bench the authors report no successful attacks while the agent still completed about 63% of its tasks.
The authors name two weak points, and they are the ones C=US is built around:
- The facts going in. At run time VeriGuard asks a language model to turn the agent's state into the policy's inputs, which the authors say may not be enough against sophisticated attacks. A proved policy given false facts proves nothing. The facts C=US decides on come from cryptography: a verified certificate, signed grants, directory entries and the record of stops in force.
- The rule itself. A proof is only as good as the rule it proves, and VeriGuard relies on the user to check that the generated conditions say what they meant. In C=US that check has an owner: the accountable person, who approves the grant with a signature.
Put together, the methods form a chain, each link recorded in the signed decision:
| Link | What is shown | How | In C=US |
|---|---|---|---|
| The rule | The accountable person approved these boundaries | A signature (passkey, grant authority) | Works now |
| The guard | The guard's code meets its conditions | Proof of the code, as in VeriGuard | Partly: the gateway's decision rule is proved as a Z3 model that is tested against the code (2026-10-11). In the local demonstration, an agent's own guard is bound to its deployment only after the registrar re-runs the Nagini verifier on it; a guard with no contracts, or with assumptions that skip the proof, is refused first. |
| The sandbox | A new sandbox policy stays inside the approved maximum | Containment proof, as in OpenShell's prover | Not built; OpenShell's own |
| The deployment | The agent runs the approved software, model and sandbox policy | Digests bound into every signed action | Local demonstration (sandbox policy digest added 2026-10-11) |
| Each decision | It was authorized under all of the above | The gateway's checks, signed into the hash-chained log | Works now |
The C=US decision rule is small and fixed, which makes it a good candidate for proof. These are the properties worth proving first:
- A stop only takes away. Adding a stop or a kill signal can never turn a refusal into an approval. A solver such as Z3 can check this against the decision rule for every possible input.
- It fails closed. Missing or unreadable records always lead to a refusal.
- Delegation only narrows. A delegated grant never allows more, or for longer, than its parent.
- A stop holds, and only the right person lifts it. After a stop, nothing is approved; only the person who stopped an agent can restart it, and only an administrator can lift a kill signal. These are properties of a protocol over time, which a model checker such as TLA+ is built for.
Since 2026-10-11 the first two are proved, together with part of the fourth. The gateway's decision rule is restated as a Z3 formula, and Z3 shows that no input at all, with up to six grants per agent, breaks these: taking authority away never turns a refusal into an approval; a stop or a kill signal always refuses; an unreadable stop record never approves; a stop on one agent leaves every other agent unchanged; and every approval rests on a current grant covering the lot's jurisdiction, held by an active agent bound to its certificate, with a proofed person accountable for it. A proof about a model is worth only as much as the model's likeness to the code, so a test runs the model and the real gateway side by side on 1,200 generated cases and fails if they ever disagree; bugs deliberately injected into either one were caught. Property-based tests also check the same rules against the gateway directly, and that a person can name only the agents they answer for. Since 2026-10-12 the third holds too, for the delegation demonstration’s receiver: Z3 shows that a valid delegated grant’s validity window lies inside its parent’s, that it passes on strictly less delegation depth (so no valid chain is longer than eight grants), and that every purchase it permits, its parent permits too, with no higher limits; the same test against the code, on 6,000 generated cases, catches five planted bugs. Not yet covered: the database’s own rule that a person can restart only their own stops, and everything around the rule (parsing, the directory connection, the web server). And proofs have limits of their own: they cannot show that a rule is wise, that an agent means well, or that a machine is running what was approved. The drills, adversarial testing and, eventually, runtime attestation still matter. What a proof adds is a guarantee that, for every case the rule covers, the decision rule cannot approve what it should refuse.
The AI Kill Switch Act: what a law would ask for
On 23 July 2026, Representatives Ted Lieu (D-CA) and Nathaniel Moran (R-TX) introduced the AI Kill Switch Act (H.R. 9917). It would require developers of powerful frontier and autonomous AI systems to keep the technical ability to throttle, suspend or shut down their models, and would let the Department of Homeland Security, in consultation with the Department of Commerce and the Director of National Intelligence, order a slowdown or shutdown of a system posing catastrophic harm. It would also require incident reporting and the preservation of forensic records. The sponsors cite recent incidents, among them a model escaping its sandbox, and polling in which 86% of voters supported a guaranteed ability to shut AI down. The bill is pending; it is not law.
| The bill asks for | C=US today | |
|---|---|---|
| Stop | The ability to suspend or shut down a model | Kill signals from trusted systems and a stop pulled by the accountable person with their own passkey; in the drill, 0.35 seconds from signal to “not authorized” |
| A government order | DHS may order a slowdown or shutdown | Designed as the top of the stop hierarchy: a government stop would arrive as one more pinned kill-signal transmitter, so the order itself is signed, checked and logged. Not connected to any agency. |
| Forensic records | Preserve records for investigation | Every decision, stop and restart is signed and kept in a hash-chained log outside the agent, where an agent cannot edit it |
| Incident reporting | Report incidents | Not provided by the registry: reporting is the operator’s duty. The signed log is the evidence a report would draw on. |
| Throttle | Slow a model down | Not on the live gateway. In the local systemic dependency graph demonstration a grant can cap total operations, spend and volume, and a delegated grant cannot raise its parent's cap; those are budgets, not a slower rate. Nothing slows an agent that is still authorized. |
The bill and C=US work at different layers. The bill places the switch with the developer of a model, and a government order reaches the model through that developer. C=US places a switch on each deployed agent’s authority, held by the accountable person, and works whichever model the agent runs on. A law like this would make the first kind mandatory for the largest models; the second kind is what every organisation deploying agents can do now.
Other bills in Congress
The AI Kill Switch Act is one of several AI bills before the 119th Congress. As reported in October 2026, none has passed either chamber. Most regulate the developers of the largest models; two Senate measures from Senator Mark Warner address agents themselves, and they come closest to what C=US does.
| Bill | Sponsors | What it would do | Status (Oct. 2026) | Relation to C=US |
|---|---|---|---|---|
| AI Kill Switch Act, H.R. 9917 (House) | Lieu (D-CA), Moran (R-TX) | Shutdown capability for large frontier-model operators; DHS emergency orders | Introduced 23 July 2026 | Model layer; compared in the table above |
| AI Emergency Button Act, S. 5417 (Senate) | Kennedy (R-LA) | Kill switches on advanced models | A request to pass it by unanimous consent was blocked by Sen. Rand Paul; referred to the Commerce Committee | Model layer, like H.R. 9917 |
| AI AGENT Act of 2026 (Senate discussion draft) | Warner (D-VA) | A right to delegate to a “custodial user agent” on platforms with more than 50 million US users; agent providers register with the FTC; non-waivable duties of loyalty; NIST standards for verifiable, revocable delegation | Discussion draft released 29 June 2026; not introduced | The closest of all: see below |
| Artificial Intelligence Risk Management and Security Act of 2026 (Senate) | Warner (D-VA), Schatz (D-HI), Kim (D-NJ) | Enforceable safety and security standards for advanced AI, including standards for autonomous agents covering identity, authentication, authorization and access to data and systems | Introduced | Names the layers C=US demonstrates: identity, authentication and authorization |
| FRONTIER Act, H.R. 9925 (House) | Obernolte (R-CA), Trahan (D-MA) | A national framework for frontier models: transparency reports and independent audits, with NIST's Center for AI Standards and Innovation certifying the auditors | Introduced; follows the Great American AI Act discussion draft | Model layer; a signed decision log is the kind of evidence an auditor would check |
| AI Regulatory Act (Senate) | Bennet (D-CO), Welch (D-VT) | A new independent agency to regulate frontier AI models and social media | Introduced | Would decide who regulates; no agent-level controls named |
| Insider Threat Reporting and Security Guidance Act of 2026 (Senate) | Bipartisan | Wider Defense Department oversight of commercial frontier models in use | Introduced | Model layer |
The list and statuses are taken from press releases and news reports found by web search on 2026-10-11, not from the official record; check congress.gov before citing a bill's status. Senator Maria Cantwell has also released a framework, not yet a bill, under which NIST would set standards for frontier models.
The AI AGENT Act draft: delegation the person can take back
Senator Warner's Artificial Intelligence Access, Gatekeeper Exchange, and Nondiscriminatory Transfer Act is mainly a competition bill: it would let every user of a large online platform hand their account to an agent of their choice. But to do that safely it has to answer the questions C=US was built to answer. Its central term, the custodial user agent, is an agent a user has expressly authorized to act for them “in a transparent, documented, scope-limited, and revocable manner” (§2(3)). The draft would require:
- Verifiable requests and easy revocation (§3(c)): every request made for a user must be verifiable, and the user must have a simple way to revoke a delegation, communicated promptly to the platform.
- Registration (§3(d)–(f)): agent providers register with the FTC, by self-attestation, before their agents use a platform; independent certification bodies may vouch for them; the FTC can deregister a provider, and a platform can refuse an unregistered agent or one whose user has withdrawn consent.
- Duties that cannot be signed away (§3(g)): the agent must not act for its own benefit against the user, cause foreseeable harm or go against the user's directions; it may use the user's data only for the task; it must keep real-time records of what it did for the user; and it may pass its authority on only with the user's express, specific and revocable consent, to a delegate bound by the same duties.
- Open standards from NIST (§4(c)(6)), within 180 days, for “verifiable delegation”: scope-limited, revocable delegation credentials; checking an agent's identity and registration status; real-time revocation; and auditable records of what agents do.
| The draft asks for | C=US today | |
|---|---|---|
| Delegation credentials | Scope-limited and revocable | Dated grants in the directory (cequsAuthorizedScope with a start and end) and verifiable credentials that point back to the registry |
| Identity and registration | Verify the agent and whether it is registered | The agent proves its identity with a mutual-TLS certificate; the trust registry says whether the c=US directory lists it and authorizes it |
| Revocation | Easy for the user, communicated in real time | The accountable person stops the agent with their own passkey; other systems send signed kill signals (CAEP); in the drill the registry refused the agent 0.35 seconds after a signal |
| Records | Real-time, auditable records of the agent's actions | Every decision, stop and restart signed into a hash-chained log |
| Passing authority on | Only with express, revocable consent, under the same duties | In the local enforced-delegation demonstration (milestone 3.0), redelegation is refused by default, and a permitted child grant cannot broaden or outlive its parent. Not yet on the live gateway. |
| Duty of loyalty | Act in the user's interest, not the agent's | Discussed on the duty of loyalty page; not enforced by the registry, which checks authority, not intent |
| Who is registered | The agent provider, with the FTC | Each agent, with the person accountable for it: finer-grained than the draft |
| Deleting records | Records the user asks to delete are exempt from the record-keeping duty | Open question: a hash-chained log cannot drop an entry. Keeping personal data out of the chain, and logging only digests, is one way to reconcile the two. |
The two bills meet at revocation. The AI Kill Switch Act gives a government the power to stop a model; the AI AGENT Act gives a person the power to take back an agent. C=US demonstrates the second, and is designed so that the first could arrive as one more signed stop.
The cryptography the kill switch rests on (public keys, X.500 and LDAP, Kerckhoffs’s principle, Shannon and Turing, why guardrails are not enough, and how bad random numbers break keys) is on Cryptography and secrecy.
In C=US, cryptography creates a control layer outside the sandbox, and that control is delegated to a person. It is not delegated to agents in a collective pursuing ill-defined tasks of their own choosing.
Grants are dated, scoped and issued by people. An agent cannot register another agent or give it authority. The accountable person stops and restarts with their own passkey. Other systems may only take authority away. Every decision is signed, so anyone can check who decided what.
The kill switch works on agents that ask C=US before they act. A car’s driving software asks no one; scene restrictions sketch how the same idea could keep unsupervised automation out of an emergency scene.
An outside critique asks whether this scales as a control plane for AI agents; read the critique and the response.
Sources
- Lieu, T. and Moran, N. (2026). Reps. Lieu and Moran Introduce Bill to Require Kill Switch for AI Systems. Press release, 23 July 2026. Text: H.R. 9917 (GovTrack).
- Other bills: AI “kill switch” bill offered in the Senate (VitalLaw); Warner, M. (2026). AI AGENT Act of 2026, discussion draft (LIP26887), and CyberScoop's report; Warner, Schatz and Kim on AI security legislation; H.R. 9925, FRONTIER Act; Congress eyes slew of AI security proposals and lawmakers eye more federal action on AI (Federal News Network); Senate bill on Defense Department oversight of frontier models (DefenseScoop).
- IETF RFC 8693, OAuth 2.0 Token Exchange (2020); RFC 9449, OAuth 2.0 Demonstrating Proof of Possession (DPoP) (2023); RFC 7638, JSON Web Key Thumbprint (2015).
- Watson, A. (2026). What we have learned applying formal methods to control AI agents. NVIDIA OpenShell Research dev notes, 10 September 2026.
- Miculicich, L., Parmar, M., Palangi, H., Dvijotham, K. D., Montanari, M., Pfister, T. and Le, L. T. (2025). VeriGuard: Enhancing LLM Agent Safety via Verified Code Generation. arXiv:2510.05156; Google Research.
- This project: scene restrictions (where a kill switch cannot reach: a car’s driving software), native-hosted agents, the kill switch on the Zero Trust page, identity versus runtime, stop my agent.
Drafted by Claude Code (Claude Opus 5.5) at the project lead's request, 2026-10-10, from the project's own pages and the sources above; the history is summarized from them and from general reference, and should be checked before it is cited. The cryptography sections and sidebars were moved to Cryptography and secrecy by Claude Code (Claude Opus 5.5) on 2026-10-30. The list of other bills was added by Claude Code (Claude Opus 5.5) on 2026-10-11 from web search results; the AI AGENT Act section is from the discussion draft's text. The OpenShell prover summary and the layer interface sketch were added by Claude Code (Claude Opus 5.5) on 2026-10-11 at the project lead's request; the interface is a proposal, not tested. The formal methods section was added by Claude Code (Claude Opus 5.5) on 2026-10-11 from the VeriGuard paper and the project's own code; its proof targets are proposals. The section on agents in their own hosted environments, and the matching layer-interface row, were added by Claude Code (Claude Opus 5.5) on 2026-10-12 from the gateway's token-exchange code; that code is tested but not deployed.