# Human in the loop for email agents: what makes approval safe

> Let an AI agent prepare emails and a person approve them. What an approval must be tied to before it really protects you, and where it breaks down in practice.

Updated: 2026-10-26 · Fact-checked: 2026-10-26 · Canonical: https://commandmail.app/en/learn/human-in-the-loop-email · Deutsch: https://commandmail.app/de/wissen/human-in-the-loop-e-mail.md

Human in the loop for an email agent means the agent writes, a person decides, and the message that goes out is exactly the one that person saw. That sounds obvious, yet it often fails in the details. An approval only protects you if the sending system checks it, if the agent cannot grant it to itself, and if it is tied to the content, the recipients and the sender.

## Why email needs approval

Under "Excessive Agency", OWASP lists three root causes of agent damage: too much functionality, too many permissions and too much autonomy. The third explicitly covers applications that fail to independently verify and approve high-impact actions[^1]. OWASP's remedy is human-in-the-loop control, where a person approves the action before it happens, and it notes this can live in the downstream system rather than in the LLM application[^1].

In email, sending is the action with the most impact. A sent message cannot be recalled, it carries your name, and it is the most direct way data leaves the inbox. Simon Willison calls the mix of private data, untrusted content and a way to communicate externally the "lethal trifecta"[^4]. An agent in your inbox reads private data and other people's mail by design. The right to send opens the most direct exit. Without it, other tools can still carry data out, such as web requests, loaded images or links[^4].

Approval does not remove that exit. It puts a person in front of it. How well that works depends on how the approval is built.

## Five properties of an approval you can rely on

The OWASP AI Agent Security Cheat Sheet describes how approval should work technically[^2]. Applied to email, five properties follow.

1. **The sending system checks it.** OWASP says the execution component must verify approval for the exact action[^3]. An agent asking itself "may I?" is not a control; the server that delivers the email has to see the approval.
2. **The agent cannot grant it.** Approval must arrive through a channel the agent does not operate. If the agent can write "approved" into a field it is also allowed to edit, nothing is gained.
3. **It covers one version.** OWASP requires a new approval when the target or parameters change[^2]. For email that means recipients, copies, subject, body, formatting, attachments and sender are all part of what was approved. A signature appended afterwards or a swapped attachment falls outside it.
4. **It is used up once.** The cheat sheet recommends checking and consuming the approval in one atomic step right before execution, so concurrent or repeated requests cannot reuse it[^2]. The trickiest email case is an unclear outcome: did the delivery service accept the message or not? An automatic retry can then send it twice.
5. **It fits the situation.** A reply written before a newer message arrived in the same thread may be out of date. A good approval flow flags that before you approve.

## Where approvals fail in practice

**Approval in chat instead of in the system.** Many assistants ask before sending. The question is useful, but it is the model's decision. A crafted email can push the model to skip it or assume consent. The OWASP prompt injection cheat sheet therefore lists human-in-the-loop controls as their own layer next to filters and structured prompts, and points to verification in the executing component[^3].

**Fatigue.** Anyone who waves through thirty approvals a day stops reading them. OWASP warns explicitly that people tire of constant prompts[^3]. Keep approvals rare enough that each one gets read: sorting, archiving and drafting need none; sending does.

**Approval for a category.** "Reply to every meeting request" is not approval of a message, it is a standing mandate. That can make sense, but it belongs with sending without approval and the limits that apply there.

**Agents that can reach the approval button.** A browser agent driving your signed-in mail app can click "Approve" as well. The separation between the agent's channel and the person's channel is gone.

**Approval without context.** If you only see the draft and not the message it answers, a forward to an unknown address is easy to miss. Recipients and attachments belong in plain view on the approval screen.

## Sending without approval: limits instead of questions

Not every message deserves a prompt. For confirmations, meeting acceptances or stock replies, autonomous sending can be reasonable. Then no approval does the protecting; hard limits enforced by the system do: a cap on messages per day, few recipients per message, no replies to automated senders and mailing lists, and a unique send key against duplicates. OWASP recommends setting autonomy by the risk of the action and keeping an audit trail of agent decisions[^2].

Be honest about the arithmetic: a deceived agent can still act within those limits. A daily cap limits the damage; it does not prevent it.

## How Command Mail implements approval

Command Mail is our product. We checked the statements below against the executing code at app commit `5a48c2b`.

An agent with `mail:draft` saves drafts; with `mail:send-approved` it may send exactly the revision a person approved[^5]. The approval route accepts only a signed-in app session; with an agent token the server answers 403 "A person must approve this draft in the browser." Before approving, the server checks for valid recipients, subject and body, whether the sending address is still the same, and whether a newer message has arrived in the thread; in that last case the approval has to be confirmed after review.

Every edit to the draft raises its revision and resets it to pending. On send, the server checks the revision and the approving person and moves the draft from approved to sending in a single step, so one approval is consumed once. Body, formatting and attachments go out as approved; no current signature is added afterwards. If the attempt demonstrably fails before hand-off to the delivery service, the approval stands. Command Mail treats any failure from hand-off onwards as an uncertain outcome: the draft is marked uncertain and the same approval does not send again.

If the sending mailbox is on the `read` autonomy level, no agent sends, not even an approved draft; you send it in the app. Sending requires Pro. Direct sending without approval via `mail:send` works only on the `auto` level, with a unique send key, an account-wide daily limit per UTC day (50 by default, adjustable from 0 to 500), at most 20 recipients per message across To, Cc and Bcc and no replies to automated senders[^5]. That permission starts switched off when you connect.

We state the limit openly: an agent that operates your signed-in browser can click the approval itself. Do not give browser agents access to the open app.

The flow from draft to sent message is in [Reply to emails with AI](https://commandmail.app/en/guides/reply-to-emails-with-ai), permissions and levels are in the [permissions documentation](https://commandmail.app/en/docs/permissions-and-autonomy), and how an email deceives an agent is explained in [Email prompt injection](https://commandmail.app/en/learn/email-prompt-injection).

## Review status

As of 2026-10-26. The OWASP and Willison pages were fetched that day. Statements about Command Mail rest on the app code at commit `5a48c2b` (approval and send routes for agent drafts, revisions, autonomy on send, daily limit and recipient cap) and on llms.txt. We have not run our own attack test.

You can [start for free](https://commandmail.app/login?signup=1) and connect your agent with read and draft permissions only at first.

## Frequently asked questions

### What does human in the loop mean for an email agent?

The agent prepares a message, and it goes out only after a person has approved that exact version. OWASP recommends this for high-impact actions so an agent never has more autonomy than the task needs.

### Is it enough if the agent asks “Shall I send this?” in chat?

Only partly. A chat confirmation runs through the same channel a crafted email can influence, and the agent itself decides whether to ask. A dependable approval is checked by the system that actually sends.

### What happens if the draft changes after it was approved?

A sound approval covers only the reviewed version. OWASP says changes to the target or parameters need a new approval. In Command Mail every edit creates a new revision that must be approved again.

### Can an agent approve its own drafts in Command Mail?

No. The approval route accepts only a signed-in app session and refuses agent tokens. That boundary does not hold for an agent that operates your signed-in browser.

### When is sending without approval reasonable?

When a wrong message would do little harm and hard limits apply, such as a daily cap, few recipients per message and no replies to automated senders. Even then a deceived agent can still act within those limits.

## Sources

1. [OWASP: LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/), accessed 2026-10-26
2. [OWASP Cheat Sheet: AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), accessed 2026-10-26
3. [OWASP Cheat Sheet: LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html), accessed 2026-10-26
4. [Simon Willison: The lethal trifecta for AI agents](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/), accessed 2026-10-26
5. [Command Mail: llms.txt](https://commandmail.app/llms.txt), accessed 2026-10-26

[^1]: [OWASP: LLM06:2025 Excessive Agency](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/), accessed 2026-10-26
[^2]: [OWASP Cheat Sheet: AI Agent Security](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html), accessed 2026-10-26
[^3]: [OWASP Cheat Sheet: LLM Prompt Injection Prevention](https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html), accessed 2026-10-26
[^4]: [Simon Willison: The lethal trifecta for AI agents](https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/), accessed 2026-10-26
[^5]: [Command Mail: llms.txt](https://commandmail.app/llms.txt), accessed 2026-10-26

---

Command Mail: one inbox for you and your AI agent. Start free: https://commandmail.app/login?signup=1 · Connect your agent: https://commandmail.app/en/agents · MCP: https://commandmail.app/mcp