Kill Switches for Superintelligent Agents: Pause Actions Safely

To stop an AI agent from taking actions, place the pause control where its actions leave your systems, such as the email server, the payment API or the messaging tool, and block those calls centrally. Keep the agent's memory and unfinished tasks in separate, durable records so a pause halts outbound work without erasing what the agent knows or what it was doing. Test the pause as carefully as the agent itself, because a stop control that has never been exercised is likely to fail when it matters most.

Key takeaways

• Enforce the pause where actions leave the company, not only in the agent's own instructions.
• Treat stopping outbound actions, holding new work and erasing state as three separate operations.
• Keep memory and task records in stores the pause does not touch, and snapshot them before any resume.
• Make external actions idempotent so a resumed agent cannot repeat a payment or message by accident.
• Write a pause runbook, name who may trigger it, and rehearse it before anyone needs it.

Why a stop instruction inside the agent is not enough

An agent that is told to stop is still a model reading inputs. A supplier email, a web page or a shared document can contain text that tries to override its instructions, and the agent may treat that text as a new command. OWASP's guidance on prompt injection stresses least privilege and human approval for high-impact actions, which points to the same conclusion: the model should not be the only thing standing between an instruction and an effect. A stop written into the prompt is therefore a request. A stop enforced by the systems the agent calls is a control.

The control belongs in three places: the gateway through which the agent reaches tools and channels, the credentials the agent holds, and the provider accounts behind them. If the gateway refuses outbound calls, the agent cannot send anything even when its reasoning goes wrong. If its tokens can be suspended on the provider side, a compromised session loses access even when the gateway is bypassed. How much authority an agent holds at each stage is a separate design question, covered in Superintelligent Agent Authorization: Growing Trust Tiers, and the pause should be designed against those tiers.

Separate three kinds of stop

Most teams picture one big red button. In practice, there are three different responses, and each should be available to a named person.

• Hold: block all outbound actions. The agent keeps reading, drafting and recording. This is usually the first response, because it stops the external effect while preserving everything else.
• Drain: stop accepting new tasks, let in-flight tasks reach a safe state, then stop work that is not yet started.
• Halt: stop the agent process itself, with memory and task records preserved in storage that survives the stop.

The common mistake is to implement only halt, usually by deleting the agent's session and restarting it. That ends the immediate action, but it also erases the context of promises made to customers, the list of what was already sent and the reasons behind open tasks. The stop itself is rarely the damaging part. The amnesia that follows it is.

A pause should change what the agent is allowed to do, not what the agent remembers.

How do you design an outbound gate that holds every action?

Route every tool call, message and external write through one gateway or broker. The gateway checks a pause state for each action class, such as customer messages, payments, record updates and file exports, and it refuses calls that fall under an active hold. The pause flag should live in a store the agent cannot write to, so that the agent cannot switch its own pause off.

Deny by default. OWASP's authorization guidance recommends enforcing access decisions on the server side and granting only the permissions a function needs. For a pause, this means the gateway should refuse any action class it does not recognize, not allow it because nobody listed it. Log every decision, including blocked attempts. Those logs are evidence of what the agent tried, and they are the first thing a reviewer will need after an incident. OpenTelemetry's observability concepts, built on traces and spans, give a useful vocabulary for following one request from the agent through the gateway to the external system.

When the gateway is in place, a hold should be confirmable within minutes by reading the logs. If you cannot show that no outbound call succeeded after the hold was triggered, the control is not finished.

What must survive a pause: in-flight work and memory?

Every external action should have a task record with explicit states, for example queued, sending, sent, awaiting reply, held and cancelled. A record that says sending is the most important one to handle carefully, because the request may have reached the provider even though the agent never received a response. Retrying blindly can duplicate a payment or a booking.

Stripe documents a clear pattern for this in its API: a client sends an idempotency key with a request, and repeating the request with the same key returns the original result rather than creating a second object. Not every provider offers this, but your gateway can apply the same discipline. Assign each external action a unique key, check whether the action already happened after a timeout, and only then retry. The result is that a resumed agent does not repeat work that was already completed.

Memory deserves the same separation. Store the agent's durable knowledge as versioned records outside its context window, so the agent's current session can be discarded without discarding what it has learned. During a hold, external triggers should not write new memory, but the system should still be able to take a snapshot. Decide in advance which actions wait for a person before they run, using the approach in Where should your AI agent stop and ask?, so that a pause and an approval queue do not collide.

What does a pause look like in practice?

A runbook turns the design into a sequence a non-specialist can follow under pressure. A workable version looks like this:

• Name the people who may trigger a hold, and a backup for each of them.
• Write the trigger conditions: unexpected send volume, a reply that commits the company to a price or a date, an outage in a connected system, or evidence that the agent received injected instructions.
• Trigger the hold at the gateway, then confirm in the logs that no new outbound call has succeeded.
• Snapshot memory and the task queue before changing anything else.
• Classify each held task as finish by hand, cancel, or keep for resume.
• Contact anyone who received a wrong message, with the correction written by a person.
• Record the reason, the evidence and each decision in the incident log.
• Resume only when a named owner approves and a test action passes through the gateway.

Illustrative scenario (not a real client): a field service company uses an agent to send appointment reminders. After a calendar sync fails, the agent begins drafting rescheduling messages for appointments that no longer exist. The on-call operations lead triggers a hold at the gateway. The agent keeps reading the calendar and drafting, but nothing leaves the company. The team snapshots the task queue, marks the drafts as held, and repairs the sync. The lead then reviews the held drafts, sends the valid ones by hand, and cancels the stale ones. Messages that went out before the hold cannot be recalled, so the incident log becomes the basis for the follow-up notes to affected customers.

In Be Human's managed operations, the gateway, task records, snapshot routine and runbook are defined in the first engagement alongside the agent's role, so the client knows exactly what a pause stops. Monitoring reviews the gateway logs, permission review confirms that credentials still match the approved tiers, and incident response follows the runbook. The client keeps the authority to pause at any time.

How do you test a pause before you need it?

A pause that has never been exercised is a hypothesis. Build a short test set that covers the failures you can predict: interrupt a send while the call is in progress, simulate a timeout after a provider has accepted a request, pause while memory writes are pending, revoke a token and confirm that the agent fails visibly rather than silently, and resume and check that no action was duplicated. Anthropic's writing on evals for AI agents recommends building evaluation sets from real failures, so each incident should add a case to the set.

Run these tests whenever the agent gains a tool, a channel or a permission, and include them in recurring evaluations rather than treating them as a one-time setup task. Keep the results in the same record as the runbook, so the person who pulls the pause next year can see what was tested and what was not. Once the pause works under test, the next question is which task deserves an agent first, and the free Be Human AI diagnostic can help you find the first task worth handing to an agent.

Frequently asked questions

Can a pause erase what the agent has learned? No, and it should not. A well-designed pause stops outbound actions and new external work, while memory and task records remain in stores the pause does not modify. If an incident calls for a full halt, the agent process can stop, but the stored knowledge and the task history should be snapshotted first and kept for review.

Should the agent be able to pause itself? It can flag a problem and request a hold, and that request is useful because the agent may notice anomalies early. The authority to enforce a hold, however, should sit with a named person and with the gateway, not with the agent's own reasoning. An agent that can switch off its own controls has no effective control.

What happens to messages that were already sent before the pause? A pause cannot recall them. The incident log should identify every message and action sent before the hold, and a person should decide whether a correction or follow-up is needed. This is why logging blocked attempts and successful sends from the start matters so much.

How often should we test the pause? Test it whenever the agent's tools, permissions or channels change, and include the tests in recurring evaluations so they run even when nothing seems to have changed. A short rehearsal of the runbook with the people who would actually trigger it is also worth doing, because the first real use should not be the first time anyone has read the steps.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.