Design Approval Gates and Kill Switches for AI Agents
The standard pitch for AI agents is full autonomy: configure the workflow, press go, let the agent handle it. For low-stakes tasks, this works fine. For tasks that modify records, submit transactions, or interact with systems that hold sensitive data, full autonomy is an engineering decision with real consequences.
Approval gates and halt controls (sometimes called kill switches in the broader literature) are the two mechanisms that keep AI agents controllable without turning them back into sequential, human-dependent processes. Platforms like Deck implement these as configurable action policies—rules defined at the workflow level that determine when the agent must pause for human approval, when it must block an action category outright, and when a session should be halted immediately.
This guide walks through the design decisions behind both mechanisms: what they are, where they should be placed, how to implement them without creating bottlenecks, and what failure modes to test before going live.
What Approval Gates Are (And Are Not)
An approval gate is a pause in agent execution where a human must confirm or reject an action before the agent proceeds. It is not an error handler, a fallback for low-confidence situations, or an exception pathway. It is a designed checkpoint—a deliberate decision that specific actions in specific workflows require human confirmation regardless of how confident the agent is.
Well-designed approval gates are:
- Scoped narrowly. Not every action needs approval—only the subset that is consequential enough to warrant it.
- Async-friendly. The agent queues the action and waits; the reviewer responds when available; the agent resumes.
- Non-blocking for unrelated work. Waiting for approval on one action should not prevent other agents or sessions from proceeding.
- Auditable. Every approval and rejection is logged with timestamp, reviewer identity, and action context. Platforms with Session Replay capture the full agent context—screenshots, reasoning trace, execution log—at the point the gate was triggered.
Where to Place Approval Gates
The right approach is deterministic placement based on action properties—not agent confidence scores.
Gate placement by action type
Irreversible writes. Any action that deletes, permanently modifies, or submits something that cannot be recalled. Platforms with configurable action policies let you block deletion actions outright at the policy level—the agent cannot execute them regardless of the instruction.
Threshold-triggered transactions. For workflows involving amounts or quantities, define thresholds above which human confirmation is required. The threshold itself is a business decision—set it with the stakeholders who own the workflow.
Scope anomalies. When the agent encounters a UI state or workflow path it has not been trained on, pause and surface the situation to a human rather than guess.
First-run verification. New agent workflows should run in full-approval mode for an initial period, with every action requiring confirmation until the workflow is certified.
Gate placement by workflow risk level
Low risk (monitoring, read-only, reversible writes): No approval gates required.
Medium risk (writes with undo, external communications, state changes with downstream effects): Gate on threshold violations and scope anomalies.
High risk (irreversible writes, consequential transactions, regulated data): Gate on all writes. Configure the action policy to block deletion categories outright.
Critical risk (real-world consequences that cannot be contained): Require human confirmation for every action outside a narrowly defined safe action set.
Designing the Approval Queue
Queue design decisions
Routing. Define routing rules explicitly by action type and workflow context. Do not default to “whoever is available.”
Notification channel. Reviewers should receive approval requests in the channel they already monitor—typically Slack or email. A gate that requires a reviewer to check a separate interface will fail any time the reviewer is in meetings.
Timeout behavior. Auto-reject with a clean session teardown is the right default for consequential actions when approval is not given within the timeout window.
Context in the approval request. Include what the agent was trying to do, what action it is requesting approval for, the relevant workflow context, and why this action triggered a gate.
See How AI Desktop Agents Use Approval Queues and Kill Switches for a deeper look at the mechanics of approval queue implementation.
Halt Controls: Design and Architecture
In the broader industry, these are often called “kill switches.” Platforms like Deck implement this as scoped action policy controls—a halt command that can be issued at the session, workflow, credential, or platform level, with defined latency guarantees and clean teardown behavior.
Scope hierarchy
Session-level: Stop one specific agent session.
Workflow-level: Stop all sessions running a specific workflow definition.
Credential-level: Stop all sessions associated with a specific credential set. Use during a security incident where a credential may be compromised.
Platform-level: Stop all sessions. Use for system-wide incidents or emergency freezes.
Each scope level should be operable independently.
Latency requirements
For most sensitive workflows, the right requirement is: a halt signal results in session stop within 5 seconds of issuance, at any concurrency level. This requires push-based signal propagation (websocket or SIGTERM)—not polling-based. Test halt latency under production concurrency levels before certifying the system.
Teardown behavior
Log the last known state. Session Replay artifacts—screenshots, reasoning traces, execution logs—should be persisted before teardown. Essential for incident investigation.
Attempt rollback for in-flight actions. If the agent was mid-action, attempt cancellation with a short timeout, then halt if cancellation does not complete within that window.
Mark partial results clearly. Output produced before the halt should be marked as partial—not promoted to completed-task status.
Do not auto-restart. A halted session must require manual intervention to resume.
Integrating These Controls Into Incident Response
When something goes wrong:
- Halt first. Stop affected sessions immediately.
- Assess scope. Determine how many sessions were affected and what actions were taken.
- Review logs. Session Replay and the audit trail should provide a complete record—screenshots, reasoning traces, execution logs up to the halt.
- Fix, not restart. Identify root cause before resuming.
- Verify in approval mode. Resume with full-approval mode until the fix is confirmed working.
This sequence only works if halt controls operate in seconds and Session Replay records are complete. If either is missing, steps one through three become much slower.
Common Design Mistakes
Over-gating. Gates on every action generate reviewer fatigue, which leads to rubber-stamping rather than genuine review.
Under-testing timeout behavior. Test explicitly: what happens when a reviewer does not respond within the timeout window?
Missing the scope hierarchy. A halt control that can only stop everything or nothing is not useful in practice.
Treating gates as error handlers. Gates should be reserved for actions requiring deliberate human confirmation, not as a fallback for agent errors.
What Good Looks Like in Production
- A review queue that is consistently short because gates are scoped narrowly
- Reviewers who take gate notifications seriously because the gates are not noisy
- Halt controls tested at production concurrency and confirmed within the defined latency window
- Session Replay records immediately available for any halted session
- Complete audit logs of every approval, rejection, and halted session
- Tabletop exercises run before a real incident