Approvals & halts

When an agent attempts something your policy marks high-risk, the run does not fail and does not proceed. It halts: the intended action is recorded, nothing is executed, and a person decides.

From the caller's side

Poll the run. When it comes back pending_approval, the response tells you what it is waiting on:

{
  "runUid": "run_01J...",
  "status": "pending_approval",
  "resumable": true,
  "message": "I found the order and prepared a refund of $240.00.",
  "pendingSteps": [
    {
      "stepIndex": 4,
      "toolName": "refunds_create",
      "riskLevel": "high",
      "input": { "order_uid": "0199a3c2-7f1e-7b4a-9c3d-5e8f2a1b6c90", "amount_cents": 24000 }
    }
  ],
  "actions": {
    "poll": "/{appUid}/agent/runs/run_01J...",
    "dashboard": "https://console.example.com/..."
  }
}

pendingSteps carries the exact arguments. The approver is not asked to trust a summary — they see the call that will be made.

A paused run showing the tool name, its risk level, the agent, and the full arguments of the call it is waiting to make — The same step as it appears to an approver — the arguments are shown, not summarised.

Treat this as a normal outcome

A halt is not an error and not a timeout. Client code should expect pending_approval, stop polling aggressively, and surface actions.dashboard to whoever needs to decide.

Approving

Approval is deliberately not an api-key operation. A key that could approve its own agent's pause would defeat the mechanism entirely — the initiator can never be the approver.

A person approves in the console's inbox, signed in with their own account. The run then resumes from exactly the step that paused, with the approved action executed. Nothing is replayed and nothing is skipped.

The approvals inbox listing three paused agent runs, each with Approve, Reject and Stop run controls — Every run awaiting a decision, across the platform arbiter and any app your organization owns.

Approve runs the step and resumes the run — as you, under the full safety invariant, so approving is never a way to exceed your own permissions. Reject records the decision against that step and leaves the run parked. Stop run is what actually ends it.

Auto-approval, and why it is a set

An agent can be configured to auto-approve, but that is not a single on/off switch. It is a set of triggers — a checklist of the specific things that may proceed without a human. An action outside the set still halts.

There is also a ceiling. An administrator sets a runaway limit that auto-approval can never cross, so a misconfigured agent cannot grant itself unlimited scope.

External callers can only tighten

An autoApprove sent in an invoke request is never honoured, and an agent's posture can be set to force human approval even when the agent would otherwise auto-approve. An external caller is the least-trusted principal in the system: it can add friction, never remove it.

Long runs pause too

Budget is treated the same way as risk. When a run reaches its step budget it pauses rather than being truncated — and a paused run is resumable, so continuing is a decision rather than a restart. A delegate hitting its budget propagates the pause up to the agent that called it, so the whole tree stops together instead of one branch silently stalling.

Stopping a run

An api key may stop its own run:

curl -X POST "$AUTHORIC_URL/$APP_UID/agent/runs/$RUN_UID/abort" \
  -H "Authorization: Bearer $AGENT_KEY"

Stopping is allowed where approving is not, for a simple reason: stopping only ever reduces what an agent does, so it cannot be used to escalate.

The governance model

Where risk levels and policies come from.

Agent Runtime API

Invoke, poll, and call tools directly.