Application GuideAgent containment

A stop button is a control boundary, not a promise

When your agent keeps acting after cancellation, Blueprint helps you design AI agent kill switches and blast-radius limits through P5, P6, P8 and P10.

By Michelangelo Zampogna · Published October 13, 2026

Key Facts

Best fit: Teams operating agents with write access, external tools, or delegated background work
Primary risk: False-stop assurance: the interface says stopped while external actions continue
Core shift: Cancel a conversation → enforce scoped containment at execution boundaries
Success signal: New actions are denied, dispatched effects are accounted for, and recovery requires approval
Doctrine mapping: P5, P6, P8, P10

Stopping is only the first step

Your team needs more than a cancelled conversation when an agent exceeds its remit. You need a scoped stop mechanism that prevents new actions, identifies work already dispatched, limits further damage, and preserves an incident record. Design those controls together so your operator can distinguish a requested stop from verified containment and an authorised return to service.

An abstract editorial illustration shows branching action paths interrupted by a boundary, with remaining effects enclosed and evidence preserved in a separate protected layer, without text. — Stop new actions, isolate effects, retain the record.

Why AI agent kill switches matter now

An agent with write access can keep affecting your systems after you close its conversation or cancel its response. P5 – Replace implied magic with clear mental models requires you to explain what stopping actually covers, while P10 – Optimise for steering, not only initiating makes interruption a first-class control.

Define separate stop scopes for one run, its delegated children, a credential, and an entire workspace; show which scope your operator is selecting (P5).

Distinguish preventing new dispatches from cancelling accepted tool requests; a completed external effect may require compensation rather than cancellation (P5).

Put stop controls on the run surface and incident surface, not only inside the conversation (P10).

Why standard AI agent cancellation fails

A cancelled model response does not establish that queued jobs, child agents, or external tool requests have stopped. P6 – Expose meaningful operational state, not internal complexity calls for an honest containment status, and P8 – Make hand-offs, approvals, and blockers explicit requires unresolved effects to have an owner and next action.

False-stop assurance: your interface displays “Stopped” after acknowledging the button press, without verifying execution boundaries (P6).

Orphaned delegation: a child worker continues because the parent’s stop state is not checked before tool execution (P8).

Credential escape: a worker can bypass your dispatcher using a long-lived credential, so local cancellation cannot enforce containment (P8).

Evidence loss: cleanup deletes the action identifiers and receipts your operator needs to distinguish attempted actions from completed effects (P6).

How Blueprint replaces cancellation with AI agent containment

Treat your kill switch as a scoped transition enforced where actions become effects, not as a message asking the agent to stop. Your interface should separately show the stop request, the enforcement acknowledgement, unresolved external effects, and the recovery decision (P5, P6, P8, P10).

Stop the action: deny new dispatches for the selected scope, including queued retries and delegated children (P10).

Contain the damage: enforce tool, resource, recipient, spend, and write-count limits outside the model; isolate affected credentials when necessary (P5).

Preserve the evidence: retain a restricted incident record with action IDs, scope, timestamps, policy decisions, and external receipts; redact secrets rather than copying raw credentials (P6).

Make uncertainty actionable: show “Dispatch blocked; 2 external requests unresolved” with a named owner instead of claiming complete containment (P6, P8).

Separate recovery from compensation: restarting work and reversing completed effects are different decisions with different approval requirements (P8).

How to implement AI agent kill switches

Start with one write-capable workflow and map every route from your agent to an external effect. Enforce stop state and blast-radius limits on those routes, then expose verified state and unresolved effects in the run interface (P5, P6, P10).

Define a run identity and parent-child scope that travel with each job and tool request; workers must not obtain unrestricted fallback credentials (P5).

Make revocation checks and dispatch admission atomic, or use equivalent fencing, so a racing worker cannot obtain fresh permission after the stop boundary is committed; track already admitted requests separately (P10).

Reject dispatch when current authorisation cannot be verified; ensure operators can invoke containment independently of the affected agent (P8, P10).

Set concrete limits before execution, such as one destination workspace, at most 20 record writes, and no external recipients; enforce cumulative limits across children and retries (P5).

Record “Stop requested”, “New dispatch blocked”, “External effects unresolved”, and “Containment verified” as distinct facts; do not let missing receipts become success (P6).

Preserve an access-controlled, tamper-evident record of decisions and receipts with a defined retention period; evidence capture must not delay urgent blocking (P6, P8).

Test stop-during-dispatch, child-worker races, delayed callbacks, unavailable policy services, and restart attempts in an isolated environment; use Blueprint validation to review the control model and UI, alongside execution tests (P8, P10).

Starter brief

Task: Update draft records in one staging workspace
Scope: Read approved sources and write at most 20 staging records; no external sends
Escalate when: A stop is requested, a limit is reached, or an external effect cannot be confirmed
Success signal: New dispatches are blocked after stop acknowledgement and every admitted action has a recorded status

Escalation and governance tiers

Use these tiers to let your operators contain activity immediately while keeping compensation and recovery behind explicit approval boundaries (P8, P10).

Tier	Action type	Risk level	Required approval
Tier 1: Scoped stop	Block new dispatches and cancel queued work within the assigned run scope	Low collateral impact; unresolved external effects remain possible	Pre-authorised for designated operators; automatic triggers defined at task start
Tier 2: Broader containment	Quarantine related runs or revoke a scoped credential affecting multiple workflows	Moderate to high collateral impact	Designated incident operator under pre-authorised emergency policy; otherwise incident owner approval
Tier 3: Compensation and recovery	Reverse completed effects, restore access, or start a replacement run	High; may repeat harm or alter legitimate work	Explicit approval from the affected resource owner and incident owner, with a reviewed recovery scope

Anti-patterns vs. Blueprint patterns

Use this comparison to find places where your interface promises more containment than your execution controls can verify (P5, P6).

Anti-pattern: Cancel the chat and label the entire workflow stopped
Blueprint pattern: Show requested stop, blocked dispatch, and unresolved external effects separately (P6)

Anti-pattern: Ask the model to respect the kill switch
Blueprint pattern: Enforce stop state at tool and worker admission boundaries outside the model (P10)

Anti-pattern: Give every worker a shared, long-lived credential
Blueprint pattern: Use scoped, revocable access and disclose any provider revocation delay (P5)

Anti-pattern: Delete logs and temporary state during emergency cleanup
Blueprint pattern: Preserve restricted action records and receipts while redacting secrets (P6)

Anti-pattern: Automatically resume once the error disappears
Blueprint pattern: Require an owner, a reviewed scope, and explicit recovery approval (P8)

Illustrative scenario

These anonymised composite traces illustrate how your containment controls could behave.

A team used a shared run dashboard to supervise a record-maintenance agent. The agent attempted writes outside its assigned workspace. The system escalated because the resource boundary check rejected the destination, then blocked new dispatches after the operator requested a scoped stop. One previously accepted write remained unresolved; the dashboard assigned receipt reconciliation to the incident owner rather than displaying complete containment.

A team used an approval queue for an agent preparing outbound notifications. The agent attempted to retry a send after a timeout. The system surfaced a blocker because the run had been revoked and the earlier send lacked a confirmed receipt. The operator preserved the request identifiers, checked delivery status, and approved a replacement run only after duplicate-send risk was resolved.

Frequently asked questions

These questions help your team distinguish cancellation, containment, and safe recovery.

Is cancelling the model response enough to stop an agent?

No: your workers, queued retries, and accepted tool requests may outlive the response. Enforce a stop at execution boundaries and show separately what remains unresolved (P5, P6).

Should every kill switch stop the whole workspace?

Use the smallest scope that can contain the suspected problem, with an explicit route to broader containment. Your operator should see the affected runs and dependencies before choosing a wider scope, unless a pre-authorised emergency policy requires immediate action (P5, P8).

What happens to a request already accepted by an external service?

Request cancellation if the service supports it, but do not assume cancellation succeeded. Track its receipt or effect until you can confirm the outcome; completed effects may need separately approved compensation (P6, P8).

What evidence should your team preserve?

Keep run and action identifiers, relevant policy decisions, dispatch timestamps, approvals, and external receipts. Restrict access, redact secrets, and set retention according to your incident and privacy requirements rather than retaining every prompt indefinitely (P6).

How do you measure whether the kill switch works?

Measure time from stop request to enforced dispatch blocking, admissions after the committed stop boundary, and time to resolve outstanding effects. Exercise races and failures in an isolated environment; interface validation alone cannot prove runtime enforcement (P6, P10).

Can your agent restart automatically after containment?

Do not let the affected run clear its own stop state. Require a named recovery owner, reconciliation of unresolved effects, and an approved scope with renewed limits before a replacement run starts (P8, P10).

Getting started checklist

Map every worker, queue, credential, and tool route that can produce an external effect (P5).
Define run-level, delegated-child, credential, and workspace stop scopes (P5).
Enforce revocation and cumulative blast-radius limits at dispatch boundaries (P10).
Show stop requested, dispatch blocked, and unresolved effects as separate states (P6).
Preserve restricted action records and receipts without delaying containment (P6).
Assign containment and recovery owners, then test races and approval gates (P8).

Validate architecture

Next steps for AI agent containment

Make one workflow demonstrably stoppable before extending the pattern across your agent fleet. Use Blueprint validation to check whether your control language, escalation path, and recovery gates match the behaviour your execution tests establish (P5, P8, P10).

In your architecture diagram, mark every execution boundary and any credential path that bypasses it (P5).

In your run interface, prototype a scoped stop and an unresolved-effects panel with named owners (P6, P8).

In your test harness, inject a delayed tool response and a racing child job; verify neither can obtain fresh admission after the stop boundary (P10).

In your incident playbook, record evidence retention, compensation authority, and the checklist required to approve a replacement run (P8).

Apply the doctrine

Run Validation

Optimise for steering, not only initiating

Read →Install Context Package

Make hand-offs, approvals, and blockers explicit

Read →