Human approval is a workflow, not a pop-up.

In short. An approval is where a workflow changes hands, and it deserves the same design attention as any other handoff. A useful approval names the action, its scope, and its consequence; shows what information the agent used; offers more than allow or deny; keeps the task resumable afterwards; and records what happened without over-collecting. A confirmation dialog does none of that. Encode which actions require a gate in the system rather than trusting the model to decide, because descriptive metadata is not a security boundary.

Approval is the moment where a workflow changes hands. A person needs to understand what the agent proposes to do, what will change, what information it used, and which choices remain available. The agent needs a clear way to pause, receive a response, and continue without losing the thread.

Why does the pop-up fail?

A modal that says “The agent wants to run send_invoice. Allow / Deny?” fails for four separable reasons.

It shows a decision without its basis. The person cannot see which customer, which amount, which source document, or which prior step produced the proposal. They are being asked to underwrite a conclusion whose evidence is hidden.

It offers the wrong choices. Real work rarely reduces to yes or no. The correct answer is often “yes, but to a narrower scope”, “not until you check X”, or “no, use the other path”.

It trains dismissal. A gate that appears for every action, consequential or not, becomes a keystroke. This is the familiar usability argument about alert and consent fatigue, applied to delegated work; it is design reasoning here rather than a claim from a specific study.

It costs the workflow its state. If denying means the agent starts over, people learn to approve rather than pay the restart cost. That is the opposite of the intended effect.

The security guidance makes a compatible point structurally. Explicit user confirmation for tool calls blocks silent escalation, while broad “allow all” permissions reduce prompts and magnify damage. The design goal is not maximum friction; it is friction placed where consequence is.

Make the decision visible

A useful approval names the action, its scope, and its consequence. It should distinguish a harmless read from an action that changes data, reaches an external system, or commits a customer-facing result.

Five elements make an approval readable:

1. The action, in the user’s language. “Email the September invoice to Acme Ltd” — not POST /v2/invoices/send.
2. The exact scope. Which record, which recipient, which amount, which time window. Specificity is what makes the difference between reviewing and rubber-stamping.
3. The consequence and its reversibility. “This sends an email immediately. It cannot be recalled.” A person’s threshold for care is set by this sentence.
4. The basis. The two or three inputs the agent used to reach this proposal, with links to them.
5. The alternatives. What the agent will do if refused, and what other paths exist.

An approval payload with that shape is easy to specify. The example below is illustrative, and the API it describes is invented:

{
  "action": "send_invoice",
  "summary": "Email invoice INV-2291 (£4,320.00) to billing@acme.example",
  "effect": "external",
  "reversible": false,
  "scope": { "invoice_id": "INV-2291", "recipient": "billing@acme.example" },
  "basis": [
    { "label": "Ledger entry", "ref": "ledger/2026-08/acme" },
    { "label": "Approved quote", "ref": "quotes/Q-1180" }
  ],
  "options": ["approve", "approve_with_changes", "request_info", "reject"],
  "expires_at": "2026-09-02T09:00:00Z"
}

Note that effect and reversible are structural fields, not decorations. They determine whether this action needs a gate at all — which is a decision your system should make, not the model.

Decide what needs a gate — in the system

The most common design error is leaving “is this consequential?” to the agent’s judgment.

Metadata is not enforcement. The Model Context Protocol specification (2026-07-28) is explicit that tool annotations — read-only, destructive, open-world hints — are untrusted unless the server providing them is trusted, and that the client and server must still validate and authorise. Those hints are excellent for selection and for shaping the interface. They are not a boundary. The rule is worth stating plainly: the model reasons over metadata; the harness enforces execution.

So classify actions server-side, by effect. The table below is a suggested default treatment rather than a standard or a compliance requirement:

Effect class	Examples	Default treatment
Read, contained	Search, fetch a record, summarise	No gate; sample in review
Write, internal, reversible	Draft, tag, create a private note	No gate; visible in history
Write, internal, irreversible	Delete, overwrite, close	Gate, with an undo window where possible
External or customer-visible	Send, publish, pay, provision	Gate, always
Scope escalation	New permission, wider access, new system	Gate, with step-up authentication

That last row has a standards answer. OAuth’s step-up authentication challenge (RFC 9470) exists precisely for the case where an in-progress session’s authentication level is insufficient for what is now being requested, and Rich Authorization Requests (RFC 9396) allow a grant to carry fine-grained authorization_details rather than a coarse scope. The broader OAuth 2.0 Security Best Current Practice (RFC 9700) is the baseline. Where a delegated grant is involved, it should answer four questions plainly: who, for which resource, for what scope, and for how long.

There is a further case that deserves an automatic gate: any consequential action taken after the agent has ingested untrusted content. Indirect prompt injection is a demonstrated attack (Greshake et al., 2023), a 2026 in-the-wild study documented injections that were hidden across many models and page representations, and design-pattern work by Beurer-Kellner et al. (2025) argues the reliable mitigation is to narrow the consequential actions available once untrusted input has entered. In approval terms: reading a stranger’s document should change what the agent is allowed to do next without asking.

Give people more than “allow” or “deny”

Real work often needs a third option: revise the request, choose a narrower scope, supply missing information, or send the task back for a different path. These options make the handoff part of the workflow rather than an interruption around it.

Four responses cover most situations:

• Approve — proceed as proposed.
• Approve with changes — the reviewer edits the scope or the parameters, and the agent proceeds with the edited version. This is the option most systems omit and most reviewers want.
• Request information — the reviewer asks a bounded question; the agent answers and re-proposes. The MCP tools specification supports multi-round-trip flows for exactly this shape, where a tool needs more input before it can complete.
• Reject with a reason — and the reason is the valuable part. A rejection reason is a product signal about a workflow that proposed the wrong thing.

One further property is worth considering, argued from the design rather than from a source: an expiry. An approval request that sits unanswered for two days can lapse cleanly rather than execute later against stale state.

Keep the path resumable

After someone responds, the system should know what was approved, what changed, and what still needs to happen. A good approval step avoids forcing either the person or the agent to reconstruct the whole task from scratch.

Resumability requires three things. The agent’s working state must survive the pause — the goal, the steps already completed, the artefacts produced. The reviewer’s decision must be attached to the specific proposal, including any edits they made. And the resumed run must be able to detect that the world moved while it waited: an approval granted against a record that has since changed should re-verify rather than proceed.

This is the same discipline as any handoff between actors. Every handoff should preserve the reason for the work covers the general case; approvals are the version where the receiving actor is a person with limited time and no context.

When the answer is “no”, resumability matters just as much. A rejection should leave the agent with a usable next state — a narrower plan, a question to ask, or a clean stop — rather than an abandoned run. That is the recovery argument in Design for recovery, not perfect runs.

Design the record with care

Teams should be able to understand what happened later without exposing more information than the task requires. The aim is practical accountability, not a surveillance trail.

A defensible record answers: what was proposed, on what basis, who decided, what they changed, when, and what happened next. NIST’s AI Risk Management Framework frames trustworthy AI as balancing accountability and transparency with security and privacy in context, rather than maximising any one of them — which is a useful reminder that more logging is not automatically better governance. Provenance work in adjacent fields makes the same trade explicit: too little provenance is useless, and too much leaks internals.

Two practical rules. Redact by default at write time, not at read time, because a log that contains a customer’s payment details is a liability regardless of who can currently see it. And keep the approval record legible to the person who will read it under pressure — usually a support engineer at an awkward hour, not an auditor with a week.

Approvals are also a measurement surface

A well-designed approval queue tells you where your workflow is weakest. Approvals granted almost every time suggest the gate is not earning its interruption and the action could be scoped smaller and automated. Frequent rejections suggest the agent is proposing the wrong thing, which is a description or context problem upstream. Long response times suggest the request is not readable enough to answer quickly.

Feed those patterns back through Evaluate decisions, not just answers rather than treating the queue as pure operational overhead.

Frequently asked questions

When should an AI agent ask a human for approval? When the action is hard to reverse, externally visible, or outside the scope the person originally delegated. Reads, drafts, and searches rarely need a gate. Payments, deletions, outbound messages, published content, and permission escalations do. Encode the rule in the system rather than leaving it to the model’s judgment.

Why is a confirmation dialog not a real approval? Because it usually shows a decision without its context. A person needs to know what will change, what information the agent used, what scope is being granted, and what alternatives exist. A dialog offering only allow or deny converts a design problem into a habit — people click through it, and the gate stops functioning as a control.

Do tool safety annotations make an approval unnecessary? No. The MCP specification (2026-07-28) states that tool annotations such as read-only or destructive hints are untrusted unless they come from a trusted server, and that the client and server must still validate. Annotations help selection and interface design. They are not enforcement.

How do we keep an approval from blocking the whole workflow? Make the pause resumable and the request specific. The MCP tools specification supports multi-round-trip flows for when a tool needs more human input, and OAuth step-up authentication (RFC 9470) exists for tasks that become sensitive partway through. Design the pause so the agent keeps its state and the person answers one bounded question, rather than restarting the task.

A well-designed approval gives people control without turning every useful workflow into a dead end.