Skip to content

Approvals

Purpose

Decide the queue of Action tool calls that paused for a person. A tool declared classification: action in the organization YAML pauses when it is called on /mcp with a key or a client connection, or when the gateway runs it inside a model call, unless its declaration says approval: none. The caller receives an in-band result naming the approval and its Console page; nothing reaches the upstream server. Approving lets the requester's identical call run exactly once; denying answers that call with your note. Managed execution uses separate durable conversation consent, not this administrator queue. That consent binds the exact stored action and original funding; backend-key consent is not a verified human.

Rules that block, redact or detect content on a tool's arguments and results are a separate control that runs on every call; see Rules on arguments and results.

Who decides

Request Decided by
A paused call of a tool enabled in a Team Anyone with approvals.decide at that Team other than the requester: Team administrators or a custom role with that permission, plus Organization administrators/owners.

A person never decides their own call: it appears under My requests and waits for someone else. An Open approval id link from Request detail appears only after the same approval-read check; a visible approval identifier does not expose its arguments. Links back to the original/executed Request require current access to that exact Team Request. The requester and an authorized current Team approver can open the relevant approval; everyone else gets the usual unavailable page.

Review the queue

  1. Open Approvals. The queue lists calls within your current decision authority.
  2. Under To decide, read the tool, the one-line arguments summary, Requested by (the requester's name, or Service account name), Team (its name), Requested and Expires.
  3. Select Decide to open the approval. The page shows Requested by with the requester identifier beneath the name, Requested, Team named and linked, Expires, Tool (the tool name on its server and the tool:<server-id>/<tool-name> resource id), Origin (Direct MCP call or Model loop, with the decision that paused) and Arguments: the exact document, validated against the tool's schema with any rule redactions applied, that runs when approved.

Nothing waiting for your decision. means no pending approval falls in your scope. A pending approval expires 24 hours after the request; an expired one can no longer be decided and shows as Expired.

Approve or deny

  1. Under Decide, enter a Note. It is optional when approving and required when denying (at most 2,000 characters); the requester reads it in their next identical call and under My requests.
  2. Select Approve or Deny.

Expected result: the page shows Approved or Denied with the time and your name, and Manage → Audit records tool_approval.approve or tool_approval.deny with you as the actor, the Team as scope and tool_approval · <approval id> as the target. A denial without a note is refused in the browser: Enter a note that explains the denial (at most 2,000 characters). An approval decided in another tab, expired, or already decided reports the service's message instead of deciding twice, and nobody can approve their own call.

Approving runs nothing by itself. The requester repeats the identical call (same actual owner/key provenance, same tool, same declared schema, same arguments) and the gateway re-evaluates everything, including current key/credential/owner/Team, allowance and policy, schema hash, budgets and rules, before it claims the approval and dispatches once; the approval becomes Executed with the decision that ran it. A further identical call opens a new approval. A denial answers identical calls with the note for 24 hours; after that the requester's next call opens a new approval.

What the requester sees

  • The first call returns HTTP 200 with result.isError: true, a text item that links to the approval page, and _meta["mission-control/code"] of approval_required alongside mission-control/approvalId and mission-control/approvalUrl; see Gateway errors.
  • Inside a model call the model reads This action needs a person's approval in Mission Control before it runs; ask again once it is approved.; the model decision succeeds and the hop's decision records approval_required.
  • Approvals → My requests lists the requester's calls with Pending, Approved, Executed, Denied or Expired and the decider's note.
  • Once approved, repeating the identical call runs it, and the client receives the tool's ordinary result.
  • After a denial the identical call returns approval_denied with the note; after the one execution an identical call returns approval_required for a new approval; a retry that lost a race with a concurrent identical call returns approval_consumed.

Verify

  • Observe → Requests: the paused call is a decision showing Approval required with a link to the approval; the executed retry is a succeeded decision citing the same approval; the tool's Connector page lists the executed call in its invocation history.
  • Audit: one tool_approval.approve or tool_approval.deny event per decision, with the decider as actor. The request and the single execution are not audit events; the paused and executed Requests and the approval's Executed status record them.
  • The upstream server received exactly one call for the approval: the paused call, the identical retries while pending, and every denied or expired retry dispatched nothing.
  • Do not verify by calling the MCP server directly; that bypasses the control being checked.