Build an off switch for the AI you already run

AI arrives in a small business one piece at a time. A key pasted into a script. An automation that files invoices, built on a slow Tuesday and never opened again. An agent given access to a shared drive because it was faster than doing the filing yourself. Each addition is small, reversible in principle, and none of them is written down anywhere. The result, a year in, is a set of processes that can act on your behalf, that you did not design as a system, and that nobody has ever switched off.

This guide is about switching them off. Not about whether AI is safe in the abstract, and not about compliance with anything, because almost none of the current rules apply to a business your size. It is about the mechanical question underneath the rules: if one of your automations started doing something wrong at 9pm on a Friday, what would you actually click, in what order, and how long would it take. If your entire use of AI is typing into a chat window and reading the answer, you can stop here; you have nothing running. This is for people whose AI holds credentials.

The question regulators started asking, scaled down

On 23 July 2026, Reps. Ted Lieu of California and Nathaniel Moran of Texas introduced the AI Kill Switch Act [2]. The bill would require a small set of companies to keep a working technical capability to stop their own systems: to stop inference, terminate user access, suspend access with respect to “an account, user, or use pattern”, and shut the technology down entirely [1]. It adds that duty to the Homeland Security Act of 2002, and lets the Secretary of Homeland Security, “acting through the Director and in consultation with the Secretary of Commerce and the Director of National Intelligence”, order the capability used after a covered incident [1]. Firms would have 15 days from discovering an incident to report it, and on receiving an emergency order would have to “preserve the model weights and telemetry” of the system [1]. Civil penalties reach $2,000,000 for each day of violation, and $20,000,000 for each day an emergency order is ignored [1].

None of that reaches you. The thresholds are deliberately narrow. Covered technology means an AI system whose compute cost exceeds “$100,000,000 at the prevailing market price of cloud computing”, and a covered entity has to derive “not less than $500,000,000 in gross revenue” a year from making it available to third parties [1]. That is a handful of labs, and the numbers will move as the bill moves.

The requirement underneath the thresholds is not narrow at all. Europe wrote a version of the same idea into binding law first: Article 14 of Regulation (EU) 2024/1689 requires that the person assigned oversight of a high-risk AI system be able to “intervene in the operation of the high-risk AI system or interrupt the system through a ‘stop’ button or a similar procedure that allows the system to come to a halt in a safe state” [3]. Two jurisdictions, wildly different scopes, the same underlying demand. Moran put it as “Stewardship means making sure humans keep the capability to control the technology we build” [2].

Scaled down to four people and eleven automations, that demand is concrete and boring. You need to know what is running, and you need to be able to stop each piece without stopping all of it. Your stack has four separate off switches, at four layers, and they fail in different ways: the credentials, the automation, the accounts the automation is allowed to touch, and the money.

Credentials you can kill one at a time

The first layer is the API key, and the mistake almost everyone makes is having one. A single key used by the invoice automation, the research script, the customer-facing chatbot and the thing you built in March means you have exactly one switch, and pulling it stops the business.

Both major vendors give you the fix. Anthropic’s Console organises usage into Workspaces, up to 100 per organisation, each with its own keys, its own rate limits and its own spend cap [4]. OpenAI’s equivalent is projects: a user inside a project generates a key that is “scoped and limited to accessing that project and its resources”, and keys carry permission levels of All, Restricted, or Read Only [6]. For anything that runs unattended, both vendors want you using a machine identity rather than your personal login. OpenAI calls it a service account, “a pseudo-user designed for system access, distinct from individual user accounts”, creatable only by organisation and project owners and scoped only to projects [6].

One workspace or project per job. The invoice thing gets its own. The chatbot gets its own. The experiment you are running this week gets its own, and gets archived when you are done. Archiving an Anthropic workspace deactivates it and archives every API key created for it in one move, which is the closest thing to a per-process kill switch the platform offers, and it cannot be undone [4]. That irreversibility is a feature at 9pm on a Friday.

Know the limits of the switch before you need it. Anthropic’s Admin API lets you list keys filtered by status and workspace and update a key to status="inactive", but there is no delete endpoint; keys are deactivated, not removed [5]. That is fine for stopping something. It is not the same as the key ceasing to exist, and if a key has leaked, deactivating it is the action that matters anyway.

The automation layer, where damage compounds

Revoking a key stops future calls. It does not undo the 400 emails already sent, and it does not stop an automation that is failing for a completely non-AI reason. The second layer is the workflow itself, and the problem here is almost never the switch. The problem is inventory.

Open Zapier, n8n, or Make right now and count the automations that are live. Then count the ones you could describe from memory. The gap between those two numbers is your actual exposure, because an automation you have forgotten is one you cannot stop, and a forgotten automation is exactly the kind that runs on a schedule against a stale assumption for six months. Write the list down somewhere outside the tool. A page in Notion, a text file, anywhere that survives you losing access to the platform. For each one, record what triggers it, which key or account it uses, and what it is allowed to write to. The last column is the one that matters, because it is your blast radius.

Then decide, in advance, which of them you would kill first. Not all automations are equal. The ones that send external communication, move money, or write to a system of record go at the top of the list. The ones that summarise things into a document you read later can wait until Monday. A shutdown plan that treats all eleven as equally urgent is a plan you will not follow under pressure.

The accounts your agent is allowed to touch

The third layer is the one people forget, and it is the one that survives the other two. When you connected an AI tool to your email, calendar or drive, you did not give it a password. You granted it an OAuth token, and that grant lives on the account side, not the tool side, which is why the place to remove it is your account settings rather than the vendor’s [7]. Turning off the automation does not revoke it. Rotating your API key has nothing to do with it.

Google keeps these grants at myaccount.google.com/linkedapps, where you open the app, choose See details, select Remove access, and confirm [7]. Google’s own warning is worth reading literally before you start clicking: “If you remove access, the app can’t access your Google Account. This may make some features unavailable” [7]. Things will break. That is the point of the exercise, and it is why you do the inventory when nothing is on fire rather than discovering the dependency graph during an incident. Then repeat the walk in every other account an AI tool has ever been connected to, starting with the ones that hold customer data or send mail in your name.

Go through those lists once a quarter. Anything you do not recognise, or connected for a trial that ended, comes off. This is the cheapest security work available to a small business, and it is the only layer nobody else can reach on your behalf.

A spend cap that refuses requests, not one that emails you

The fourth layer is money, and it is the only one that works while you are asleep. An agent in a retry loop does not announce itself. It just calls the API, fails a check, calls again, and keeps going until something stops it. The thing that stops it should be a limit you set, not your bank.

Read the fine print on what “limit” means at your vendor, because the default behaviour differs and the difference is the whole point. Anthropic lets you cap monthly spending per workspace on the Spend limits tab, set alert thresholds, and separately cap requests per minute and input and output tokens per minute for that workspace; those workspace limits must be equal to or lower than the organisation’s [4]. One quirk to plan around: a spend limit cannot be set on the Default Workspace, which is another reason not to run production work there [4]. OpenAI supports monthly spend limits at both organisation and project level, and states the choice plainly: “A spend limit can monitor spend without enforcement, or you can enforce it as a hard limit so API requests fail after spend reaches the limit” [6]. If you leave it soft, OpenAI’s documentation is equally plain about what happens when you cross it: “API requests will continue to be processed without interruption” [6].

A soft limit is a smoke alarm in a house nobody is in. Set the hard cap. Set the per-minute rate limit too, because a rate limit stops a loop in seconds while a monthly spend cap only stops it after the money is gone. To size the cap, take your real monthly spend and roughly double it. The arithmetic is small: Claude Sonnet 5 runs $2 per million input tokens and $10 per million output, and Claude Opus 5 runs $5 and $25 [8], so a chatty agent making a few hundred calls an hour is cheap per call and expensive per night.

The drill that turns a plan into a switch

Everything above is a list of buttons. A list of buttons is not a kill switch until somebody has pressed them in order and written down what broke. This is the part that gets skipped, and it is the only part that distinguishes a business that can stop its AI from one that believes it can.

Budget an hour. You do the drill once, then repeat it whenever the stack changes materially. Pick your highest-risk automation. Actually stop it: deactivate its key, switch the workflow off, revoke its account grant. Time each step. Note every other thing that broke as a consequence, because there will be at least one you did not predict, and finding it now is the entire return on the exercise. Then turn it all back on and write the sequence down as a numbered procedure, stored somewhere you can reach from your phone.

The written procedure needs one more thing that people leave out: who is allowed to run it. In a four-person business the answer is usually everyone, and it should be explicit, because the failure mode is not that nobody can stop the system, it is that the person watching it go wrong at 9pm is waiting for permission from someone asleep. Name the people. Give them the credentials they need to actually do it, not read-only access to watch it happen.

What still goes wrong

The plan above stops future actions. It does not reverse past ones, and that asymmetry is permanent. If an agent has already sent the emails, filed the wrong numbers, or replied to a customer in your name, no switch retracts any of it. Every hour of undetected wrong behaviour is an hour of cleanup, which means detection speed matters more than shutdown speed, and detection is the part none of this guide fixes. Spend alerts catch runaway loops. Nothing catches an agent that is quietly wrong at normal volume.

The second gap is that shutdown is not free, and you will feel that during the drill. Revoking an OAuth grant breaks features you were relying on, exactly as Google warns [7]. Archiving an Anthropic workspace is irreversible and takes its keys with it [4]. A real stop procedure trades availability for control, and if you have never priced that trade you will hesitate at the moment you need to move fast. Better to find out during a rehearsal on a Tuesday.

The third is regulatory. The AI Kill Switch Act is an introduced bill, not law, and its thresholds are the kind of number that changes in committee [1]. The EU’s Article 14 stop-button requirement is binding but attaches to high-risk systems, which is a defined category that most small-business automation sits outside of [3]. Nobody is coming to audit your kill switch. That is the argument for building one on your own schedule rather than under a deadline, and it is also the honest reason most people will not.