AI drafts, a person approves: the gate before AI emails a customer

A hypothetical case: an online shop lets an AI assistant answer complaint emails on its own. In the middle of the night, the AI promises a customer a full refund, although the shop's policy does not allow it.

This article covers the gate between an AI drafting a message and that message leaving your system: which actions need a person, what the approval screen shows, why reviewers approve without reading, and how to measure it. Sources are documents from OWASP, OpenAI, Anthropic, NIST and Google PAIR.

Click Star already has articles on AI agents, tool calling and prompt injection; this one covers the approval step. Click Star sells AI integration services, so its own frameworks are labeled as such.

Key points

• A human reviewer (human-in-the-loop) matters most for actions that leave the system or are hard to undo. OWASP calls missing approval for high-impact actions "excessive autonomy".
• Split AI actions into 6 types by risk: read, draft, send outside, write data, money, delete (a Click Star framework).
• The approval screen must show the exact content about to run, not just "AI wants to send an email".
• Reviewers can tire and approve without reading. Anthropic names "approval fatigue" and reports Claude Code users accept 93% of manual prompts (a coding-tool figure, not a measure of not reading). NIST calls over-trusting machines automation bias.
• Block at the application layer, not only in the prompt. OWASP advises checking authorization in the downstream system.
• Loosen one action type at a time, based on your own measurements, with after-send sampling. No outside source gives a standard threshold.

Let AI send, or wait for a person: where is the line

The line follows the consequence of the action, not how capable the AI is. Human-in-the-loop, meaning a person sits inside the process, means the AI proposes and a person decides before the action runs.

OWASP calls this risk "Excessive Agency" (entry LLM06:2025, no date shown). The root causes are too much functionality, too many permissions and too much autonomy.

For a mailbox assistant that a malicious email could push into forwarding sensitive mail, an OWASP fix is making the user review and press send on every message the AI drafts.

According to NIST (AI RMF 1.0, January 2023), some AI systems need no human oversight, such as models that improve video compression, while others do. Click Star suggests that, for a Vietnamese company, each type of AI action have a named owner.

6 types of AI action, ordered by risk

This is a Click Star reference framework, not taken from an outside source. If an action fits several types, use the highest-risk one: an email promising a refund counts as "money", even though its form is "send outside".

• Read: look up an order, view history. Can be automatic if access is read-only and limited to the asking customer's own data (least privilege, per OWASP).
• Draft: the AI writes but nothing leaves the system. Can be automatic if drafts stay in a drafts folder with no path to auto-send.
• Send outside: email, Zalo, a public post. Hard to take back, so each item needs a reviewer, at least at first.
• Write data: edit a CRM record, change an order status. Needs a reviewer, or auto-write only when it can be undone and is logged.
• Money: refunds, discounts, quotes. Always needs a reviewer with authority.
• Delete: irreversible. Always needs a reviewer; better, remove the capability from the AI if it is not needed (OWASP: keep functionality minimal).

What the approval screen must show

The screen must show the exact content about to be sent, not a summary. The Claude Code Agent SDK document "Handle approvals and user input" works this way: the application receives the tool name and parameters so the user can decide.

OpenAI's Agents SDK guide adds: treat tool names and arguments as untrusted content, filter sensitive values and escape them before rendering HTML.

Click Star suggests an approval screen with 5 parts (Click Star framework):

• The exact content to send, with the recipient and the channel.
• The data the AI used to write it, such as which order and which policy passage.
• Highlighted parts: amounts, dates, commitments.
• 3 buttons: Send, Edit then send, Reject with a reason.
• A line recording who approved and when.

Reviewer rights and logs. OpenAI's Agents SDK guide tells the server to authenticate the reviewer from the login session, not the request body, and to refuse replacement arguments from the client. Click Star suggests logging every decision: who approved, when, and what was decided.

Why reviewers click approve without reading

Because repetition wears attention down, and people over-trust machines. Anthropic (post "How we built Claude Code auto mode", March 25, 2026) calls the first effect "approval fatigue": users stop noticing what they agree to.

The same post gives a number: Claude Code users accept 93% of manual permission prompts. This is a coding tool, the post does not describe the sample, and it does not measure not reading or email review.

NIST calls the second tendency automation bias, excessive deference to automated systems. In its generative AI profile (NIST AI 600-1, July 2024), it says this can worsen the risk of AI making things up.

The review "Complacency and Bias in Human Use of Automation" by Parasuraman and Manzey (Human Factors 52(3), 2010, DOI 10.1177/0018720810376055; abstract read via Crossref) reports it occurs in novices and experts alike, and cannot be prevented by training or instructions alone.

So telling reviewers to "read carefully" is not enough. Make reading easy and rubber-stamping hard. These suggestions are Click Star's own, with no source measuring their effect:

• Cut the number of items to review by removing surplus functions and permissions first.
• Put high-risk items first and highlight amounts, dates and commitments.
• Do not allow bulk approval of "money" and "delete" items.
• Occasionally queue a test item with a known error to see whether reviewers read, and tell the team in advance.

Block in the application, not only with a prompt instruction

In Click Star's view, an instruction like "do not send before approval" in the prompt (the text that instructs the model) is a soft layer. The firm layer is your own software between the model and real systems such as email. The model only proposes; the application presses send.

OWASP calls this "complete mediation": check authorization in the downstream system, not in the model. OpenAI ("Guardrails and human review", no date shown) describes the same idea: the model may decide an action is needed, but the run pauses until you approve or reject it.

OpenAI's approval cycle has 4 steps: the run records an approval request instead of running the tool; the result returns pending items; the application approves or rejects; the application resumes the same run.

The page also advises, for multi-agent "manager" workflows, placing checks next to the tool that causes side effects instead of only at the first and last agent. The email sender is Click Star's example of such a tool.

When the reviewer is away, Anthropic says that with always_ask the session pauses and waits indefinitely. OpenAI's guidance for authorized security workflows says to fail closed when review times out or is unavailable. Click Star suggests a default: no reviewer, no send, plus a backup reviewer.

Do not confuse approval with automatic mode. Anthropic says the auto policy in Managed Agents is not a human checkpoint: if the server judges a call safe, it runs before anyone sees it.

When to loosen, and how to sample after sending

Loosen one action type at a time, once your own measurements are stable. This 3-stage framework is Click Star's:

• Stage 1: a person reviews every outgoing message, and edits are recorded.
• Stage 2: a low-risk type (for example, confirming a request was received) moves to auto-send once the edit rate is low and stable, with sampled review after sending.
• Stage 3: "money" and "delete" keep mandatory approval.

Each company sets its own "low" threshold and sampling rate; Click Star has no outside source for a number. Sample heavily at first, reduce gradually, and return to full review at the first serious error.

Google PAIR says some errors are noticed by neither user nor system and need their own quality assurance process; Click Star reads after-send sampling as such a process.

How to measure: is the approval step working

Measure in 3 groups and read the numbers together; this metric set is Click Star's proposal.

Draft quality. Share of drafts edited before sending, share rejected, rejection reasons, complaints found after sending. Click Star already has an article on evaluating AI chatbots.

Speed. Time from draft to decision, items waiting, time the customer waits.

Does the reviewer really read. Time the content stays open before approval, consecutive approvals with no edit, and results on test items with deliberate errors if you use them.

A low edit rate is not automatically good: the AI may write well, or the reviewer may not read. Only the third group and after-send sampling can tell.

Click Star's view. There are 3 technical and governance judgments. First, put reviewers where actions are hard to undo, instead of approving everything and wearing reviewers out. Second, the approval step is part of the product: it needs design, measurement and gradual correction.

Third, the rules must live in application code, not only in the prompt. For a small Vietnamese team with few support staff, the first gate to build is the one before any message about money or commitments. These are Click Star's inferences from the documents cited, not based on measurements from any project.

What to do in 4 weeks

This plan is a Click Star reference framework, not a measurement.

• Week 1: list everything the AI can do, sort it into the 6 types, and remove unneeded functions and permissions. Name an owner and a backup for each type.
• Week 2: build the 5-part approval screen and the log. Put the approval rules in code, defaulting to "do not send" without a reviewer.
• Week 3: pilot on 1 channel with full review, and record edit rate, rejection rate and review time.
• Week 4: read the numbers with the "does the reviewer really read" group, decide which type to loosen, and set the sampling rate.

Common mistakes

1. Trusting an instruction in the prompt instead of blocking at the application layer.
2. An approval screen that shows only "AI wants to send an email, agree?", with no exact content or data source.
3. Putting every action into 1 queue, so reviewers are flooded and click through.
4. Allowing bulk approval of "money" or "delete" items.
5. Letting the system send on its own when nobody has approved, instead of defaulting to no send.
6. Loosening without sampling after sending.
7. Treating a low edit rate as proof that the AI writes well, when the reviewer may not be reading.

What is not known

Click Star has no independent measurement of how often reviewers approve without reading when checking AI drafts to customers at Vietnamese companies. Anthropic's 93% figure comes from users of a coding tool.

No source Click Star could open gives a standard threshold for edit rate, sampling rate or review time, and Click Star has not read any study measuring suggestions such as putting high-risk items first or inserting test items with errors.

Click Star read only the abstract of Parasuraman and Manzey's 2010 study, as the publisher's page could not be opened with its tools.

Anthropic's Managed Agents is in beta. Agent Builder, OpenAI's tool for building multi-agent workflows and separate from the Agents SDK cited above, will shut down on November 30, 2026, per the "Safety in building agents" page. This article gives no legal advice on responsibility when AI emails personal data; ask a legal professional.