Pending actions and the approval flow

Pending actions are the Worker confirmation path for agent writes. They separate proposal from execution.

Tier behavior

Tier	Router behavior
T1	Read-only or simulate; executes immediately.
T2	Executes immediately unless a T2 guardrail escalates it to review.
T3	Queues a pending action before execution.
T4	Destructive. Curated hard-blocked tools never execute; other T4 tools queue destructive pending actions. Public destructive confirmation is blocked.

Studio API-key rotation and revocation are queued even though they are T2, because the router treats them as approval-required.

Hard-blocked destructive tools

The router blocks these T4 tools before any delegate call:

Tool
`inblack_refund_order`
`inblack_merge_crm_contacts`
`inblack_disconnect_bank_connection`

They return INBLACK_T4_BLOCKED.

Queue response

When a tool needs approval, the router returns:

{
  "status": "needs_confirmation",
  "error_code": "INBLACK_CONFIRMATION_REQUIRED",
  "tier": "T3",
  "pending_action_id": "pending_...",
  "preview": {
    "schema_version": "2026-05-01",
    "tool_name": "inblack_create_journal_entry",
    "tier": "T3",
    "args_hash": "..."
  },
  "summary": "Created pending action pending_... for inblack_create_journal_entry. Ask the user to approve it, then call inblack_confirm_action with this pending_action_id."
}

The pending action stores a redacted argument snapshot, an action preview, preview hash, correlation data, initiator, tier, status, and audit identifiers.

Confirm or reject

The catalog tool is:

inblack_confirm_action

Input:

{
  "pending_action_id": "pending_...",
  "approved": true
}

Use approved: false to reject. Approval re-validates visibility, destructive policy, preview hash, argument hash, kill switches, and execution context before dispatching the original tool.

Public surface rules

The public MCP surface can create T3 pending actions. It cannot confirm destructive pending actions. If a pending action has destructive tier, public confirmation returns INBLACK_T4_BLOCKED.

Code-mode and non-interactive contexts

Some execution contexts cannot queue pending actions. In those contexts, a T3 or review-escalated T2 returns INBLACK_CONFIRMATION_REQUIRED with a summary that the tool cannot be queued from the current execution context.

For code-mode, this matters because financial-state writes must still go through MCP. Code that needs that write must invoke the MCP tool and respect the confirmation result.