How to require human approval before an AI agent sends email

Short answer

To require human approval before an AI agent sends email, remove the agent's direct send capability and route every outbound message through a gate that returns a decision. The agent may only send when the gate says allow or when a human resolves the request as approved. A rule in the system prompt is not a gate: the model can rationalize past it, and a prompt injection can talk it out of it. The gate has to live outside the model, in code the agent cannot call around.

There are three common ways to build that gate: approve everything (a drafts folder), pause the agent framework on the send tool (for example LangGraph human-in-the-loop), or run a policy preflight that allows low-risk mail and escalates only risky sends to a person. The rest of this post compares them and shows the preflight version with SendGuard.

Pattern 1: every email becomes a draft

The agent can create drafts but has no tool that sends. A person reviews each draft and sends it.

• Good for: low volume, brand-new agents, regulated teams in their first weeks.
• Cost: a human reads 100% of the mail, so the agent saves writing time but not review time.
• Failure mode: reviewers start rubber-stamping once volume grows, which quietly turns the gate off.

Pattern 2: interrupt the agent on the send tool

Frameworks such as LangGraph can pause execution when the agent calls send_email, persist state, and resume after a reviewer approves, edits, or rejects.

• Good for: teams already running one agent framework end to end.
• Cost: you still build the review queue, notifications, timeouts, audit log, and idempotency so a resumed run does not send twice.
• Failure mode: every send still interrupts, so it has the same review-volume problem as drafts unless you add your own risk rules.

Pattern 3: policy preflight, escalate only the risky sends

Before each send, the agent calls a preflight API with the sender, recipient, message, and context. The API returns one of four decisions:

1. allow: send now.
2. delay: hold and retry later, for example while a new mailbox warms up.
3. requires_approval: create an approval request and wait for a person.
4. block: do not send.

Each decision comes with a risk score, reason codes such as SENSITIVE_INDUSTRY, PRICING_CLAIM_DETECTED, or MAILBOX_TOO_NEW, and recommendations. Humans only see the mail that tripped a policy, so review effort scales with risk instead of volume.

• Good for: AI SDRs, lead-generation agents, and recruiting or healthcare outbound where some mail is routine and some is sensitive.
• Cost: you call one more API per send, and you still decide what your policy is.
• Failure mode: a policy that is too loose. Start strict and loosen it as delivery outcomes come back.

Preflight gate in code

This is the whole gate. The agent is given guarded_send as its only email tool; send_email is never exposed to the model.

import requests

SENDGUARD = "https://api.sendguard.ai"
HEADERS = {"Authorization": "Bearer sk_live_xxx"}

def guarded_send(draft, send_email):
    resp = requests.post(
        f"{SENDGUARD}/v1/preflight/email",
        headers=HEADERS,
        json={
            "workspace_id": "ws_demo",
            "agent_id": "sdr-agent-01",
            "policy": "balanced",
            "from": {"email": draft["from"]},
            "to": {"email": draft["to"], "industry": draft.get("industry")},
            "message": {"subject": draft["subject"], "body": draft["body"]},
            "context": {"intent": "cold_outbound", "relationship": "new_prospect"},
        },
        timeout=10,
    )
    resp.raise_for_status()
    result = resp.json()

    if result["decision"] == "allow":
        send_email(draft)
        return {"sent": True}

    # delay, requires_approval, and block never reach the mail provider here.
    return {"sent": False, "decision": result["decision"], "reasons": result["reasons"]}

A reviewer works through pending requests with GET /v1/approvals?status=pending and resolves each one with POST /v1/approvals/{id}/resolve and a body of {"status": "approved"} or {"status": "rejected"}. Only approved requests are handed back to the sender.

After sending, report what happened with POST /v1/feedback/outcome (delivered, bounced, complaint, replied, or unsubscribed). Outcomes feed sender health, so an agent whose mail starts bouncing gets more conservative decisions without a code change.

Which pattern to choose

• Fewer than about 20 AI emails a day and a nervous team: start with drafts.
• One framework, one agent, and engineers who want to own the review UI: interrupt on the send tool.
• Hundreds of AI emails a day, several agents, or a sensitive audience: preflight and escalate only risky sends.

The patterns stack. Many teams preflight everything and still route requires_approval into the same review UI they built for drafts.

What a preflight gate does not do

A preflight decision is advice to your sender, not a send. SendGuard does not deliver email, does not guarantee inbox placement, and cannot stop a send path you left open. If the agent can still reach your mail provider directly, the gate is optional, and optional gates fail.

Try it on your own flow

The SendGuard $1 pilot is a one-time $1 purchase for 100 production preflight checks. It is not a subscription. Run a redacted or synthetic version of one real AI email through it and check whether the decision and reasons would have changed what your agent did. Full request and response fields are in the API docs.

FAQ

Is a system-prompt rule like "always ask before sending" enough? No. The model can ignore or rationalize past instructions, and prompt injection can override them. Approval has to be enforced by code that holds the send capability.

Does every email need a human? Not with a preflight gate. Low-risk mail returns allow and sends immediately; only mail that trips a policy returns requires_approval.

What should happen when an approval times out? Treat a timeout as rejected. Never let an unanswered approval default to sending.

How is this different from email verification tools like ZeroBounce or NeverBounce? Verification answers whether an address is likely deliverable. A preflight gate also asks whether this agent should send this message to this recipient now under your policy. See the comparisons.