Approvals

Held calls wait in one inbox at /dashboard/runtime/approvals, where you read, approve, deny or vote. The inbox is on every plan, because calls can be held on every plan. An agent whose call is held gets APPROVAL_PENDING with a link and is told to call again with the same arguments.

Approval requests go out to Slack, Microsoft Teams, email, Mattermost and webhooks.

An agent can submit a plan before it starts. Once approved in the inbox, the plan becomes pre-approvals scoped to that agent and that session. Plans never cover another session and never skip a block. A step may declare the highest tier it covers, shown to the approver.

POST /v1/runtime/plans

Remembering an approval covers calls similar to the one you approved by default, not the tool with any arguments. A remembered approval never covers a call of a higher tier than the approved one. See what each scope covers, and what it never covers:

GET /api/runtime/approvals/:id/scopes

An approval rule can require a justification. A call that would ask a person must then carry action.purpose, or it is blocked with approval.justification_required. The reason (up to 1,000 characters) is shown to the approver as the agent's own words. Clients that cannot send a reason yet, such as MCP clients, model-proposed tool calls and coding-agent hooks, are blocked by these rules.

An approval binds to Intertrace's own hash of the arguments (canonical JSON, SHA-256), to the MCP server when there is one, and to the session it was asked in. A client's own hash is only checked, never trusted. If the model rewrites the call, it is a new approval, and the card shows what changed from the version you approved.

With self-approval prevented, the person who started a call cannot approve it. The one exception avoids deadlock: the requester may decide only when nobody else in the organization can, and one approval is enough.