The kill switch you actually control

At some point you gave an AI system access to something real. A repository, an inbox, a database with customer names in it, a key that can move money. It happened gradually, one convenient integration at a time, and nobody wrote it down. Somewhere behind that is a question you have probably never answered out loud: if this thing does something you did not ask for, what stops it, how fast, and who does the stopping.

Containment is two separate problems that get discussed as one. The first belongs to the labs, and it is whether a model that starts behaving outside its builder’s intent can be caught and shut down inside the company that made it. You cannot audit that, and you are not going to solve it. The second belongs to you, and it is the distance between a wrong action and the moment access actually stops. That one is entirely buildable, mostly boring, and almost nobody does it. This guide is for a solo operator or small team that has given an AI agent real access. It is not for anyone who already has a security team and a vendor risk process, and it is not for someone who only uses a chat window to draft emails, because there is very little there to contain.

What a lab’s safety framework actually commits to

Three of the big labs publish a document with a version number on it, and the version number is the useful part. Anthropic’s Responsible Scaling Policy is at version 3.4, effective 8 July 2026 [1]. OpenAI’s Preparedness Framework is at version 2, published 15 April 2025 [2]. Google DeepMind’s Frontier Safety Framework is at version 3.1, dated 17 April 2026 [3].

What they commit to is a threshold structure. Anthropic’s policy says that reaching certain Capability Thresholds requires upgrading safeguards to the ASL-3 Security Standard or the ASL-3 Deployment Standard, where deployment protections include access controls, real-time classifiers, asynchronous monitoring and jailbreak detection [1]. OpenAI tracks three categories with mature evaluations, biological and chemical, cybersecurity, and AI self-improvement, and defines High capability as needing safeguards that sufficiently minimise the risk of severe harm before deployment, with Critical capability adding the same requirement during development [2]. Google DeepMind’s framework describes identifying capability levels, running detection protocols across the model lifecycle, preparing mitigation plans for severe risks, and involving external parties when appropriate, and the company publishes safety reports for its Gemini models [3].

Read carefully, none of these is an incident runbook. They govern whether a model ships and under what safeguards, not what happens to your API key at three in the morning. OpenAI’s framework routes decisions through a Safety Advisory Group that reviews safeguards and recommends to leadership, with recommendations ranging from approving deployment to requesting further evaluation or stronger protections, and the final call sits with leadership [2]. Anthropic’s policy notes the company remains free to pause development in circumstances it deems appropriate [1]. Those are reserved rights and governance structures. They are worth something, and they are not a promise about your account.

So use the frameworks for what they are: evidence that a process exists, dated and versioned, which is more than a page about values gives you. A vendor that can point you to a document with an effective date has at least written the thing down. A vendor that cannot has not.

Regulators are turning the promise into a filing

The voluntary phase is ending, slowly. California’s SB 53, the Transparency in Frontier Artificial Intelligence Act, was signed on 29 September 2025 [4]. It requires large frontier developers to publish a framework on their website describing how they have incorporated national standards, international standards and industry-consensus best practices, and it creates a mechanism for frontier AI companies and the public to report potential critical safety incidents to California’s Office of Emergency Services. It protects whistleblowers who disclose significant health and safety risks from frontier models, and it creates a civil penalty for noncompliance enforceable by the Attorney General [4].

In Europe, the governance rules and the obligations for general-purpose AI models became applicable on 2 August 2025, and the AI Act itself became applicable on 2 August 2026 [5]. Providers of general-purpose models that may pose systemic risks have to assess and mitigate those risks [5]. Reporting of serious incidents and malfunctioning is a separate duty, and it falls on providers and deployers across the Act rather than on the frontier tier alone [5].

For you, none of this creates a hotline. What it creates is paperwork you are allowed to read, and paperwork that has to stay current. That changes the vendor conversation from “do you take safety seriously”, which every vendor answers identically, to “show me the current published framework and the last time it changed”, which not every vendor can answer at all.

Your containment perimeter is the credential, not the model

Nothing you do changes how a model behaves. What you control is what a credential can reach, and how quickly it stops working. That is the whole perimeter, and it is built out of platform settings you already have access to.

On OpenAI, work is organised into projects, each with its own API keys, and an organisation can create up to 2,000 of them by default [7]. Key permissions come in three shapes: All, which grants full permissions; Restricted, which lets you set None, Read or Write per endpoint; and Read Only, which sets read permissions across all endpoints [7]. Service accounts created at the project level are unique to that project and cannot be used outside it, and project resources such as files and assistants stay scoped to the project rather than moving between them [7].

On Anthropic, the Admin API is the equivalent lever. An admin can list API keys filtered by status and by workspace, or organisation-wide, and deactivate one by updating its status to inactive [6]. Workspaces have create, get, list, update and archive endpoints, member roles run from user and claude_code_user through developer, billing and admin, and there are separate APIs for usage and cost and for reading configured rate limits [6]. Notably, the documentation says you create API keys in the Console and the Admin API can only read, rename and change the status of existing keys [6], which means the destructive direction is automatable and the permissive direction is not.

The practical rule that falls out of this is unglamorous: one credential per job, named after the job. A key called “n8n-invoices” that you can deactivate at speed, without first working out what else it was quietly powering, is worth more than an elegant permission matrix nobody remembers. The reason to split credentials is not tidiness. It is that a shared key cannot be revoked in a hurry, so in practice it never is.

One honest caveat on money as a control. On OpenAI, setting a monthly spend limit establishes soft spending thresholds for a project, with customisable alerts, and the system does not enforce hard caps by default [7]. A spend limit of that kind is a smoke alarm, not a fire door. Set it anyway, because noticing early is most of the job, but do not build a plan that assumes the number holds.

Permission rules beat instructions, every time

The single most useful sentence in any vendor’s documentation on this subject is in Claude Code’s permissions page: permission rules are enforced by Claude Code, not by the model, and instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they do not change what Claude Code allows [8]. That is the durable principle. Enforcement has to live outside the thing being enforced.

The mechanics are worth knowing because they generalise. Claude Code documents six permission modes [8]. default prompts on first use of each tool and is labelled Manual in the interface. acceptEdits auto-accepts file edits and common filesystem commands in the working directory. In plan, Claude reads files and runs read-only shell commands to explore but does not edit your source files. auto auto-approves tool calls with background safety checks that verify actions align with your request. dontAsk auto-denies tools unless they were pre-approved. bypassPermissions skips prompts [8]. Rules are evaluated in a fixed order, deny then ask then allow, with the first match deciding and specificity making no difference [8]. A deny rule that names a bare tool removes that tool from Claude’s context entirely, so the model never sees it, while a scoped rule such as Bash(rm *) leaves the tool available and blocks matching calls [8]. Path rules do the same job for files, so Read(./.env) or Read(./secrets/**) keeps a directory out of reach, and a Read deny rule also blocks Edit and Write on the same path [8].

The documentation is blunt about the dangerous mode too. It says to use bypassPermissions only in isolated environments such as containers or VMs where Claude Code cannot cause damage, and it offers permissions.disableBypassPermissionsMode set to “disable” in a settings file, which is most useful in managed settings where it cannot be overridden [8]. That last detail is the shape of every good control: the person being restricted is not the person who can lift the restriction.

Rehearse the revocation and time it

Write down every credential an AI system currently holds. API keys per project or workspace, OAuth connections you approved once inside an assistant, whatever your automation platform stores, the tokens sitting in an environment file on a server you have not logged into since spring. Most people who do this properly find at least one they had forgotten, and the forgotten one is the whole point of the exercise.

Then cut one off, on a Tuesday afternoon, deliberately. Revoke it in the place it actually lives, and Anthropic and OpenAI both make that a specific screen or call rather than a support ticket: keys deactivated by status on Anthropic [6], keys scoped to a project on OpenAI [7]. Confirm it is dead by making a call that now fails, because a key you believe is revoked and is not is worse than one you never touched. Write down what broke, and how you knew.

The total matters less than the inventory. If the number is twenty minutes and the list is complete, you are in good shape. If the number is four minutes because you could only think of two keys, you have not measured containment, you have measured your memory.

Four questions worth asking a vendor

The first is where the safety framework lives, what version it is on, and when it last changed. A good answer looks like a URL with a version and an effective date attached, in the shape of a policy at version 3.4 effective 8 July 2026 [1] or a framework at version 3.1 dated 17 April 2026 [3].

The second is who decides to restrict or halt a deployment. You are looking for a named body rather than a vibe, of the kind OpenAI describes when a Safety Advisory Group reviews safeguards and makes recommendations to leadership [2].

The third is what gets reported, to whom, and on what trigger. There are now external answers to point at, including California’s incident reporting mechanism through the Office of Emergency Services [4] and the EU’s serious incident reporting duties [5]. A vendor in scope should be able to say which of those apply to them.

The fourth is the one that actually protects you: what can I revoke myself, in what unit, and how fast. Per key, per project, per workspace, per connection [6][7]. That answer is verifiable this afternoon, which none of the other three are.

What still goes wrong

Every framework here is self-graded. A version number tells you a process exists and gets revised; it does not tell you the safeguards work, and it gives you no visibility into what happens inside the company after an incident. Treat a published framework as a hygiene signal, roughly the way you treat a security certification: its absence is damning, its presence is weak evidence.

Your own perimeter leaks too, and the documentation says so. Blocking a fetch tool by domain does not prevent network access if the agent can still run shell commands, because it can reach any URL with curl or wget [8]. File deny rules apply to the agent’s own file tools and to file commands the harness recognises in a shell, but not to arbitrary subprocesses such as a Python script that opens files itself, which is why OS-level sandboxing exists as a separate answer [8]. Spend limits are soft thresholds rather than hard caps [7]. Every control has a shape, and every shape has an outside.

The deepest limit is timing. Containment is a race between a wrong action and someone noticing, and nothing in this guide shortens the noticing half. An agent that runs unattended overnight can do a night’s worth of damage against controls that would have worked fine if you had been watching. If you cannot say roughly how long a misbehaving agent would run before you saw it, that gap is your real exposure, and no amount of key hygiene closes it. Either put a human in the path of anything irreversible, or accept that your containment plan starts the morning after.