How AI Desktop Agents Use Approval Queues and Kill Switches
Two mechanisms separate AI desktop agents that can be safely deployed in production from those that cannot: approval queues and halt controls.
Both are straightforward in concept. An approval queue pauses the agent and waits for a human to confirm an action before it executes. A halt control (sometimes called a kill switch in the broader industry) stops the agent immediately, regardless of what it is doing.
Platforms like Deck implement these as configurable action policies—workflow-level rules that define which actions require human approval, which action categories are blocked outright, and when a session should be halted. What is less straightforward is the technical architecture that makes these mechanisms reliable under real conditions, the edge cases that break naive implementations, and the operational patterns that determine whether they are actually used effectively.
What Approval Queues Actually Do
A production approval queue is a durable message queue, not a process-level pause. When the agent reaches a checkpoint, it:
- Serializes the pending action into a structured record: what action was requested, what workflow context triggered it, what the relevant data is.
- Writes the record to the queue. The queue is persistent—it survives agent process restarts, network interruptions, and platform-level incidents.
- Suspends the session. The agent session moves to a waiting state. Depending on the platform, the VM may be paused (preserving its state) or the workflow state checkpointed and the VM released to free compute resources.
- Triggers the notification. A notification is dispatched to the defined reviewer via Slack, email, or an in-platform dashboard.
- Waits. The session remains suspended until it receives a decision.
When the reviewer responds:
- Approved: The queue delivers the approval, the session resumes, the agent executes the pending action.
- Rejected: The session receives the rejection and takes the defined rejection path—typically aborting and logging.
- Timeout: If no decision arrives within the timeout window, the queue triggers auto-rejection with a clean session teardown and a logged record of the timeout.
The key property is durability. The approval record exists independently of the agent session. If the reviewer is unavailable for hours, the action waits without consuming compute resources. If the platform experiences an outage, the queue persists and can be drained when the platform recovers.
The Approval Notification Problem
The most common approval queue failure in production has nothing to do with the queue architecture. It has to do with the notification.
The correct approach is to deliver approval requests to the channel reviewers already monitor—Slack or email. An effective notification:
- Arrives in a channel the reviewer is actually watching
- Contains enough context to make a decision without navigating to another application
- Includes an approve/reject interface operable directly from the notification
- Escalates to a secondary reviewer if not acted on within a defined interval
The last point—escalation—is underimplemented in most approval systems. If a reviewer is unavailable, the approval request should not simply time out; it should escalate to a secondary reviewer.
What Makes an Approval Decision Good
An effective approval request includes:
The specific action being requested. The actual record, values, and targets involved—specific enough that a reviewer can verify the action is correct without navigating to the source system.
The workflow context that triggered this request. Which workflow is running, which step produced this action, and whether this is routine or anomalous.
Why this action triggered a gate. “This action exceeded the $25,000 approval threshold” is more useful than a generic “approval required” message.
A clear indication of what happens if rejected. The reviewer should not have to guess at the downstream consequence of their decision.
The option to request more context before making a decision.
How Halt Controls Work
In the broader industry, the mechanism to stop an agent session immediately is often called a “kill switch.” Platforms like Deck implement this as a scoped action policy control—a halt command that can be issued at the session, workflow, credential, or platform level, with defined latency guarantees and clean teardown behavior.
The signal path
The critical property is push-based propagation. The control layer must reach running sessions directly and immediately, not wait for sessions to check in. Sessions that poll for halt signals on a timer can take 30–60 seconds to respond. Sessions that receive push signals via websocket or process signal respond in milliseconds.
Test propagation latency explicitly at production concurrency. Confirming that 100 concurrent sessions all halt within 5 seconds is a different engineering problem than confirming it for 1 session.
The scope hierarchy
Session-level: Stop one specific session.
Workflow-level: Stop all sessions running a specific workflow definition.
Credential-level: Stop all sessions using a specific credential set. In Deck, this maps directly to Deck Vault credential scoping—revoking a credential in Deck Vault immediately makes it unavailable to new sessions.
Platform-level: Stop all sessions. For system-wide incidents or emergency freezes.
Teardown behavior
Session Replay and log flush. Session Replay artifacts—screenshots, reasoning traces, execution logs—should be persisted before teardown. If the VM is destroyed before the log is written, the incident investigation loses the most recent actions.
In-flight action handling. If the agent was mid-action, attempt cancellation with a short timeout, then halt if cancellation does not complete within that window.
Status reporting. Report final status—halted, halted with partial action, halted with action completed—to the control layer before teardown.
No auto-restart. A halted session must remain halted until a human explicitly resumes it.
The Operational Layer: Who Can Halt, Who Can Approve
Halt access should be broad within the organization. Any operator, security team member, or engineer on call should be able to stop agent sessions if they observe concerning behavior. Halt controls that require going through a vendor support process will not be used quickly enough when needed.
Approval authority should be narrow and well-defined. The answer should be specific roles, not “whoever is around.” Vague approval authority leads to requests bouncing between people who each assume someone else is handling it.
Both should be documented and practiced. Run drills—issue a halt signal and time how long it takes for all sessions to stop. Run tabletop exercises for off-hours approval scenarios. Systems that have only been designed but never practiced tend to have gaps that appear under pressure.
What Good Looks Like
An organization with well-implemented approval queues and halt controls has:
- A real-time Live Agent View dashboard showing all active sessions, their states, and any sessions in the approval queue
- Approval requests arriving in reviewers’ primary communication channel with enough context to decide without additional investigation
- Halt controls any authorized operator can use immediately, stopping sessions within seconds at any concurrency level
- Session Replay records available immediately for any halted session
- Deck Vault (or equivalent) credential scoping that allows a single credential to be revoked across all active sessions instantly
- Documented approval chains with explicit escalation paths
- Practiced halt drills run before production launch