An AI agent kill switch: four layers, and what each one actually stops

The short answer

An AI agent kill switch is not one control. To stop an agent that is doing damage, you need four layers:

1. Refuse its next call at the point where its tool calls leave for real systems.
2. End work already running, such as a long query in the database.
3. Revoke its credentials, so a copy of the agent, or a script it wrote, can’t carry on.
4. Hold its writes until a person has looked at what happened.

Each layer misses something the next one catches. Write the four steps into a runbook before you need it, and practise it once.

Why killing the process isn’t enough

The obvious move is to kill the agent’s process or close the chat. That stops the loop that decides what to do next. It doesn’t stop:

• a database query the agent already sent, which keeps running on the server;
• a background job or scheduled task the agent created;
• another copy of the agent, on another machine or in CI, using the same key;
• a script the agent wrote, still holding a connection string.

And it destroys evidence. The process’s memory held what the agent was trying to do. A stop that happens outside the agent, and records every refused call, keeps that information.

The four layers

The order is deliberate. Layer 1 is fastest and loses nothing. Layer 2 stops the damage in progress. Layer 3 is slower, because rotating a credential breaks things that legitimately use it, but it closes the paths you didn’t know about. Layer 4 is how you come back without the same thing happening again.

Layer 1: refuse the next call

If your agent’s tool calls go through one place, a gateway, an MCP proxy, a tool layer you control, that place is where the fastest stop lives. It should:

• refuse every call from the stopped agent with a clear reason the agent can read;
• record each refused call, because an agent that keeps trying is information;
• take effect on every instance of the gateway, not just the one you clicked.

The last point is easy to get wrong. If you run three gateway instances behind a load balancer, a stop held in one instance’s memory lets two thirds of calls through.

In Deedglass, Stop refuses every call from one agent, or from every agent in the organisation, until a person starts them again, and each refused call is still recorded. A stop is committed together with a notification to every instance; each instance also checks every 500 ms that it can hear its own notifications, and reads Postgres directly when it can’t. So a stop is honoured on every instance within 2 seconds, even when a notification is lost.¹

What this layer can’t do, stated in the same docs: it doesn’t kill the agent’s process, revoke credentials the agent holds elsewhere, or roll anything back, and a tool call already running when the stop lands finishes or times out.¹ That is why layers 2 and 3 exist.

Layer 2: end what is already running

A refused next call doesn’t touch the UPDATE that started thirty seconds ago. For Postgres, find the agent’s sessions and end them:

Code A database command in SQL. The text around it says what it does.

-- what the agent's role is running now
SELECT pid, state, now() - query_start AS running_for, left(query, 80) AS query
FROM pg_stat_activity
WHERE usename = 'agent';

-- cancel the current query, or end the whole session
SELECT pg_cancel_backend(pid)    FROM pg_stat_activity WHERE usename = 'agent';
SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE usename = 'agent';

pg_cancel_backend cancels a session’s current query; pg_terminate_backend ends the session. A role can signal sessions of roles it’s a member of, or with pg_signal_backend privileges.³ One subtlety: without a timeout, pg_terminate_backend returns true once the signal is sent, whether or not the process has ended.³ Run the first query again to confirm.

Do the same for whatever else the agent can start: CI jobs, queue workers, scheduled tasks. Check for jobs it created, not only the ones it was given.

Layer 3: take back the credentials

Assume the agent’s credentials have been copied into places you don’t know about: a file it wrote, a log, another agent’s context. Revoke them at the source:

• Database: ALTER ROLE agent NOLOGIN; to block new connections, then layer 2 for the open ones.
• Cloud and SaaS keys: revoke or rotate in the provider’s console.
• Tokens in files: search the repository and the agent’s working directory for anything that looks like a key.

This is the slow layer, and the one people skip because it breaks things. That is a reason to give each agent its own credentials in the first place: revoking an agent’s own key breaks only that agent. A shared admin key means a kill switch that takes down production too. The blast radius entry explains why per-agent keys matter.

Layer 4: hold writes until a person looks

After the emergency, the agent comes back. The question is how. Turning everything back on at once invites a repeat. A safer pattern is to let reads run and hold writes until someone has reviewed what happened.

Deedglass’s lockdown does a version of this automatically. In lockdown, after an agent’s action ends as “can’t check”, that agent’s writes are refused in every session until a person acknowledges the action; reads still run.² Turning lockdown off needs two different owners or admins, and there is no API route that turns it off.² That second rule matters for a kill switch: the agent’s own credentials should never be able to turn the safeguards off. Our lockdown for hospitals post covers the design.

Then repair. Undo the writes you can, restore from backup what you can’t, and read the first hour after an agent deletes data for the order of operations. For rolling back an agent session’s rows, see undo for agent sessions.

A runbook you can copy

Print this and fill in the blanks for your own setup:

1. Refuse new calls: the command or button, and who can press it. ______
2. End running work: the pg_stat_activity query above, with your agent’s role name. ______
3. Find everything else it started: jobs, branches, scheduled tasks. ______
4. Revoke credentials: each key the agent holds, and where to revoke it. ______
5. Preserve the record: export the gateway’s records and database logs before anything rotates them. ______
6. Hold writes: how the agent comes back read-only first. ______
7. Restart: who decides, and what they check first. ______

Practise it on a staging agent once. The first time you run a kill switch should not be the day you need it. The checklist before an agent touches production includes this step. To see refusals and checks on a real database in your browser, open the playground; to grade what an agent can reach on your machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.