Approvals

Some actions are legitimate but too risky to automate — deleting cloud resources, running a destructive command, filing changes in an external system. For these, the agent runtime supports deferred approval: the agent pauses mid-task on a designated tool call, asks a human, and only proceeds if the human approves.

How an approval works

Specific tools on an agent can be marked as requiring approval. When the agent is about to call one of them:

1. The task is paused — not failed. Anyone checking the task's status sees it in a deferred state.
2. A notification is delivered to the configured approver destination (typically a Slack channel) describing what the agent wants to do — the tool name and a summary of its arguments.
3. An approver decides:
   • Approve — the tool runs and the task resumes as if it had never paused. The conversation continues normally.
   • Reject — the approver is prompted for a reason; the tool call fails with that reason, and the task ends in a failed state.
   • No decision in time — each approval has a timeout (minutes, not hours). If it expires, the call is automatically denied and the task fails. Silence never means yes.

Every step is captured as audit events: the pause, the decision (with the approver's identity and note), or the timeout.

Approving from Slack

When approvals are routed to a Slack channel the agent is connected to, the notification arrives as an interactive message with Approve and Reject buttons. Approving resolves the request immediately; rejecting opens a short dialog asking for a justification, which is recorded with the decision. After the decision, the message updates to show the outcome and who made the call.

For stricter control, an agent can carry an approver allowlist — a set of email addresses that are the only identities allowed to resolve its approvals. A decision from anyone else is refused and the request stays pending for a listed approver. This fails closed: an approver whose identity cannot be verified is treated as unauthorized.

What users of the agent see

From the requesting user's point of view, the agent simply takes longer on that step. If they are chatting with the agent through a channel, the conversation resumes seamlessly on approval. On rejection, the agent receives the failure — including the approver's reason — and can explain to the user why the action was not taken.

A pending approval does not hold the rest of the conversation hostage. The paused task is detached from the connection that triggered it: a chat channel holds its request open for a bounded window (about six minutes), but if that window closes before the decision lands, the task stays parked until its own approval timeout and still resumes and completes when approved — a late approval finishes the work rather than hitting a dead task. What a late approval loses is only in-place delivery: the result is not pushed back into the original chat exchange once that connection has closed. Keeping approval timeouts within the chat window still gives the smoothest experience, so design approval flows for a responsive on-call audience, not a queue reviewed hours later.

Per-user connection consent

Approvals answer "may the agent take this action?". A related but distinct gate answers "has this user connected their account for this tool?". Some integration tools act with the requesting user's own identity rather than the agent's — the agent files the ticket as you, not as a shared service account. The first time a request needs such a tool and the requesting user has not connected their account yet:

1. The call parks in an auth-required state (distinct from the deferred approval state) while the task waits.
2. The user receives a Connect link — delivered over Slack when the agent is connected to Slack, otherwise surfaced through the console — and signs in to the external service with their own account.
3. Once the sign-in completes, every parked call for that user and that service resumes automatically. One consent covers the service, not just the single call — the user is not asked again on their next request.

If the user declines, the parked call fails immediately rather than idling; if they do nothing, the wait expires (about ten minutes) and the call fails with an authorization-required error the agent can relay to the conversation.

Credential custody stays on the platform: the user's grant is vaulted platform-side, and the agent only ever receives short-lived access tokens minted from it — no long-lived credential is stored in the agent. The agent never holds a delegated token for more than about five minutes, even when the external provider issues longer-lived ones — so disconnecting a user's account on the platform takes effect within minutes, not whenever the provider's token happens to expire. The wait, the resolution, and any timeout are recorded as audit events (mcp_auth_required, mcp_auth_resolved, mcp_auth_timeout).

Use an approval when a human must confirm a specific action; the consent gate only establishes who the agent is acting as. A sensitive write can sit behind both — the user's connection satisfies the consent gate once, and the approval still fires on each action.

When to use approvals

• Actions that are dangerous but sometimes correct — use an approval so a human confirms the specific instance.
• Actions the agent should never take — do not use an approval; block them outright with the agent's policies and guardrails.
• Auditability requirements — approvals attach a named human decision to the action, which appears in the platform's Security area.

Full runtime detail — the deferral lifecycle, notification targets, and the consent-gate protocol — lives in the developer section: Deferred authorization and Delegated consent.