How to Write the Approval Request a Human Can Actually Decide On

Approving everything is the fastest way to destroy the control. Reviewers who see a prompt for every benign read learn to click through, and the approval becomes a formality rather than a safeguard (NHI Mgmt Group on human approval workflows). Research on agent approval workflows is blunt about the tradeoff: frequent prompts reduce automation value and cause habituation, while rare prompts can miss high-impact combinations (Pomerium).

The practical rule: gate on irreversibility, external effect, money, privilege, and data disclosure. Read-only retrieval, classification and internal drafts can usually run under policy. External messages, deletions, permission changes, payments and credential operations get a hard, synchronous pause (Pomerium).

A worked example makes the sizing concrete. If an agent drafts 400 internal notes a day and 6 customer emails, putting all 406 behind one queue guarantees rubber-stamping. Put the 400 on sampled review (say 5 percent) and the 6 on a hard gate with full context. Reviewer attention is the scarce resource; spend it where a mistake is expensive.

The reviewer needs a resolved payload, not a plan. Pomerium's guidance is to render security facts from normalized tool data and trusted resource lookups, because the model can explain the action but the approval view must not depend on the model's prose (Pomerium). The same point appears in reviewer-facing guidance: a generic "the assistant wants to update records" forces operators to guess and turns oversight into a rubber-stamp liability (Exemplary's approval guide).

A complete card carries six things:

• The operation. The canonical tool or API call, not a description of it. crm.billing.issue_credit_memo tells the reviewer more than "issue a refund" (Exemplary).
• The target. Explicit account, tenant, resource URI or recipient list, resolved from the trusted system of record.
• The payload and the diff. Exact parameters, and what changes from the current state. For a refund: amount, currency, reason code, and the prior state.
• The acting identity. Which service principal executes, and on whose behalf. The reviewer must be able to see that the execution credential cannot exceed their own authority.
• The evidence. Document identifiers, clause and page offsets, the source records the agent relied on, and which fields came from untrusted content (Pomerium).
• The undo. The reversal or compensating operation, if one exists, stated plainly. crm.billing.void_credit_memo or "no reversal, email cannot be recalled."

A compact render of that payload looks like this:

ACTION    send_email (campaign.bulk_send)
TARGET    segment: customers/us/trial-expiring-14d  -> 148 recipients
PAYLOAD   template: trial_expiry_v3, subject: "Your trial ends Friday"
EFFECT    irreversible after send; ~148 external recipients
EVIDENCE  segment built from billing.trials (snapshot 09:14 UTC),
          3 recipients excluded by consent filter
UNDO      none. Draft can be deleted before send.
ASK       Approve sending this email to 148 customers?

If a field would not change a reviewer's answer, cut it. If cutting it means the reviewer cannot tell what will happen, the card is broken, not the reviewer.

Internal reasoning is not evidence. A chain of thought is narrative the model generated, and it can be fluent, plausible and wrong in the same paragraph. Showing it invites the reviewer to grade the story instead of checking the payload, which is precisely the failure mode where the UI shows an agent summary while hidden arguments target another account (Pomerium).

Hide:

• Raw tool logs and stack traces, unless an error changes the decision.
• Token counts, latency, model choice and routing decisions.
• The agent's deliberation, confidence scores and self-critique.
• Data that is irrelevant to this action, especially sensitive data the reviewer does not need, such as full customer records when a name and account ID suffice.

Show, in collapsible form, the normalized arguments and any material uncertainty. The tradeoff is real: previewing every field improves transparency and can overwhelm users, so the recommended pattern is a stable summary with expandable raw normalized data and clear differences from the prior state, and never hiding recipients, permissions or destructive scope (Pomerium). The paper form analogy holds: the exception form asks whether restricted data such as PHI, PII or PCI is involved, because that answer changes who must sign. It does not ask which font the request was typed in.

The question on the card should be answerable without scrolling. "Proceed?" is not a question, because it names no object. "Approve sending this email to 148 customers?" names the verb, the object and the count. The count matters because it is the thing a reviewer can sanity-check against the segment they expect.

Four rules for phrasing:

1. Verb first, object second, scale third. "Approve rotating the signing key for tenant eu-1?" beats "Key management action pending review."
2. Offer the right decision set. Approve and reject is often too narrow. Add modify (fix one parameter, keep the rest) and escalate (route to someone with more authority), and make the buttons say what they do: "Approve exact," "Edit parameters," "Reject with note" (Exemplary).
3. Default to reject on timeout. Silence must never execute a write. A timeout should abort and abstain, not approve (Exemplary).
4. Say what the approval does not cover. One click that approves a bundle of unknown size or future actions is a known failure case (Pomerium).

This mirrors good practice in identity systems, where a policy triggers extra authentication only when it is needed rather than for everyone, and where risk policy authors trade friction against coverage deliberately (Okta on conditional MFA for Entra ID, Microsoft on configuring risk policies). Microsoft's guidance is explicit that choosing a higher risk threshold reduces how often a policy fires but excludes lower-risk events, and that blocking is often worse than letting users self-remediate (Microsoft Entra risk policies). The agent equivalent is: gate fewer, more consequential actions, and give the reviewer a way to fix rather than only to block.

An approval is worthless if it can drift. The reviewed action must be cryptographically or transactionally bound to the action digest, the approver identity, the policy version, the task and a short expiry, and the executor must compare the digest before executing. Single-use approvals should be consumed atomically. Keep authorization at the tool and target independent, so an approval never substitutes for permission (Pomerium).

This is where most homegrown review screens fail. Three scenarios to test:

• Time of check to time of use. Change the recipient, raise the amount, or delete the target between display and execution. The system must revalidate or stop (Pomerium).
• Replay. Present an old approval after resource state changed. The digest and expiry must reject it.
• Fatigue. Train users on low-value prompts, then slip one high-value prompt into the stream. Risk-based gating is the defense.

There is a good precedent in identity governance: an exception to an authentication policy should name a business justification, an owner, a scope, compensating controls, an expiry and a review cadence, and without those it stops being a controlled risk decision and becomes an unaudited bypass (NHI Mgmt Group on MFA exceptions). Treat every "allow once" on an approval card the same way. If your system lets a reviewer approve indefinitely, with no expiry and no revalidation, you have built a bypass with a nice UI.

Approval is a workflow state, not a sentence in a prompt. Production-grade implementations pause the run, serialize the state, and resume the same run when a decision arrives, rather than starting an unrelated conversation (Promptessor's HITL guide). That has concrete design consequences:

• Durable state. If approval may take hours, the run state must be stored and restored, with pending requests re-emitted after restoration (Promptessor).
• Routing. Send the card to a role, not a person, and escalate after a defined window rather than leaving work stranded.
• Evidence packs. The goal is a decision in seconds. A card that requires research is a card that gets rubber-stamped (StackAI's approval workflow guide).
• Batching, carefully. Batch low-risk internal items into one screen; never batch external or irreversible ones.
• Audit. Record the action digest, displayed facts, approver, decision, time, policy, expiry, execution identity and final effect, and keep the target system's own audit event as well (Pomerium).

Access request management literature makes the same distinction well: a ticket tracks a request, a governed workflow documents every grant from request to revocation (Zluri's access request guide). An agent approval card that logs only "approved at 14:02" is a ticket. One that logs what was shown, who signed, under which policy and what executed, is governance.

Use this as the acceptance test for an approval card before an agent gets write access.

If the card passes all ten, an approval means something. If it fails the payload or binding rows, a yes is a signature on a blank page.

When you are wiring this into real systems across several model providers, the plumbing is often the slow part. Quanta Inference puts text, image, video, audio and embedding models behind one OpenAI-compatible API key, which keeps the agent runtime and the approval service talking to one endpoint while you build the gates (Quanta Inference). And if the harder question is which of your workflows should be gated, automated or retired, a short working session with people who have shipped these systems is often faster than a design doc (Quanta Consulting).