Approvals and consents

Two governance gates pause an agent mid-run and wait for a person:

• Approvals — a compliance rule (or a static defer rule in the agent's configuration) parked a governed tool call until a named approver decides it, or a workflow reached an approval gate authored into the flow.
• Consents — a tool that acts as an individual user needs that user to connect their own account before the call can proceed.

Both are personal surfaces, scoped to the signed-in user — they are not admin-gated like the rest of the Governance area.

My Approvals

My Approvals is a top-level item in the console: the queue of governed actions currently parked waiting for your decision — tool calls deferred by a compliance rule, and workflow approval gates reaching a human decision point. A deferral appears here when its approver list names your signed-in email — it is a personal queue, not a shared admin inbox, and a deferral that names no individual approvers appears in no one's personal queue.

Each pending approval shows:

• the tool operation the agent wants to call and the agent asking,
• a human-readable context summary of the call and its argument values,
• how long ago it was parked.

Approve lets the agent proceed with the parked call; Deny refuses it — either way the decision is relayed to the waiting agent immediately, and the run resumes or moves on. The queue refreshes itself every few seconds, so a gate another approver decided, or one that timed out, drops out on its own.

A deferral that nobody decides within its timeout expires and the call is refused (see deferral routing for how timeouts compose). The queue shows open gates from the last 24 hours — a deferral cannot outlive its timeout, so anything older is treated as closed.

The decision is attributed to your verified signed-in identity, and the whole lifecycle is auditable in the event stream: task_deferred when the call parks, task_deferred_decision when an approver decides it, task_deferred_timeout when it expires undecided.

Workflow approval gates

Workflows can pause on approval gates — human decision points authored inside the workflow itself, distinct from the compliance deferrals above. When a run reaches a gate that names you as an approver, it appears in the same My Approvals queue, alongside your parked tool calls; approving resumes the run, rejecting fails it. A Completed tab keeps the decision history — approved, rejected, and timed-out gates — next to the live Pending queue. The gate's lifecycle is recorded as approval_requested, approval_granted / approval_rejected, and approval_timeout in the event stream. For authoring gates and how a paused run behaves, see Running and monitoring workflows.

Approvals over Slack

When an agent has Slack connected and the deferral's route targets a Slack channel, the approval prompt is delivered there as an interactive message — approvers can decide from Slack without opening the console. The route (and whether it targets the platform inbox, Slack, or email) is configured per agent on its Governance tab.

Pending consents

Some tools act as the individual user rather than as a shared service identity. The first time an agent makes such a call for a user who hasn't connected their own account, the call parks and a consent gate opens: the platform asks that user to connect before the call can proceed.

How the user is prompted:

• Over Slack — when the agent has Slack connected, the user receives a direct message with a Connect link.
• In the console — under Connected Accounts, which lists every service the user can connect, their current connection state, and any open consent gates waiting on them.

Connecting hands the browser to the service's own sign-in and consent screen (standard OAuth). The platform stores the resulting grant — agents only ever receive short-lived access tokens minted from it — and the parked call resumes automatically once the connection completes. Disconnecting removes the grant; the next call that needs it parks again.

A consent gate resolves when the user connects (or explicitly declines) and times out if they never do. Open gates are derived from the event stream — mcp_auth_required events with no later mcp_auth_resolved or mcp_auth_timeout for the same agent, service, and user. In a workflow run, a step blocked on consent additionally shows as workflow_step_waiting, so a paused workflow is visibly waiting on a person rather than stuck.