What to Do If an AI Agent Sends an Email You Didn't Approve

If an AI agent sends an email you didn't approve, your first move is neither panic nor silence. Open your provider's undo-send or recall option immediately, because that window is measured in seconds to minutes, not hours. Then, whether or not the retraction actually works, tell the recipient what happened before they find out on their own. This is the same incident-response pattern used when an AI coding agent leaks a secret or deletes production data, applied to a failure mode this blog has not covered directly yet: unauthorized external communication sent under your name, to someone outside your team who cannot see your internal recovery process. It sits inside the same category of AI risk this blog tracks across agent failures.

Why This Failure Mode Is Different

An agent that deletes a database table or commits a credential causes damage you can usually contain inside your own systems: restore from a backup, rotate the key, revert the commit. An agent that sends an email cannot be walked back the same way. The message exists on someone else's server the instant it leaves yours, and the retraction window closes faster than most people expect. The only lever you fully control after that point is how honestly and quickly you respond, not whether the message can be un-sent.

The Immediate Response Checklist

Work through these steps in order; do not skip the recipient notification while you investigate.

1. Attempt retraction or recall right away. Check whether your email platform offers an undo-send window or a recall function, and use it before doing anything else.

2. Pull the exact content that was sent. Get the full body, subject line, attachments, and recipient list from the sent-items folder or the agent's action log, not from memory.

3. Notify the recipient directly. Send a short, honest message explaining that an automated system sent the email in error and, if relevant, what in it should be disregarded.

4. Loop in your team. Tell whoever owns the relationship with that recipient, and loop in legal or compliance if the email contained anything sensitive, financial, or contractual.

5. Preserve the evidence. Save the agent's logs, the prompt or task that triggered the send, and any tool-call records before retention windows roll them off.

6. Audit exactly which permission or trigger let this happen. Trace the specific scope, tool grant, or automation rule that allowed an outbound send, not just "the agent did it."

7. Decide on a follow-up correction. A short clarifying email or a phone call often does more to preserve trust than a long internal explanation the recipient will never see.

Notify the Recipient Honestly, Not Quietly

Staying silent because the email "probably wasn't a big deal" is the most common way this incident gets worse. Recipients who later learn that a company knew about a stray email and said nothing tend to read that as concealment, even when the original mistake was minor. A short, plain message sent within the hour costs little and closes the loop before the recipient has to guess what happened or forward it to someone else.

Audit the Trigger, Not Just the Symptom

The email itself is a symptom. The real question is which permission or trigger let an agent take an outbound, external-facing action without a human confirming it first. Common culprits: a broad "send email" tool grant never scoped to draft-only, a chained automation where one agent's output silently triggered another agent's send action, a common failure point in agentic AI systems, an ambiguous instruction the agent read as authorization to contact someone directly, or a webhook that fired on stale data. Naming the specific mechanism, not just "AI made a mistake," is what lets you close the actual gap instead of only apologizing for the outcome.

The Same Incident-Response Pattern, a New Failure Mode

This is the same three-part pattern this blog has covered for other agent failures: contain what you can, tell the truth to whoever is affected, and find the exact permission that allowed it. The coding agent that committed a secret to a repository and the agent that deleted production data both caused internal damage you could investigate and repair on your own infrastructure. An unauthorized outbound email is the external-facing version of the same incident: it leaves your system boundary and reaches a person who has no visibility into your recovery process, which is exactly why the recipient notification step matters more here than in an internal-only incident.

Prevention Framework: Approval Gates vs. Safe Defaults

The structural fix is the same one that works for agent-initiated spending: separate actions that stay inside your system from actions that leave it, and require explicit human approval for the second category. Any action visible to someone outside your organization, sending an email, posting publicly, messaging a customer, should require confirmation by default. Read-only research, internal note-taking, and drafting should be the agent's default posture; sending should be an exception it has to ask permission for, not a capability it already holds.

In practice this means giving agents a draft-only mode for anything email-shaped, so the agent prepares the message and a person clicks send. It means scoping "send" permissions narrowly, to an approved list of recipients or domains rather than an open capability, and adding a single confirmation click between drafting and delivery. Treat any tool grant that touches an external party the same way you would a spending limit: bounded, logged, and reviewed, following the same approach outlined in how to set spending limits for AI agents. Teams that already maintain an incident response plan for AI agents should add this failure mode to it explicitly, since the response steps differ from an internal data or code incident.

Most agent work, drafting, searching, summarizing, internal automation, has no external blast radius and does not need a human in the loop at every step. The gate belongs specifically at the boundary between your systems and everyone else's inbox.

Frequently Asked Questions

Can you actually recall an email after an AI agent sends it?

Sometimes, and only briefly. Gmail's undo-send feature holds outgoing mail in a short delay window before it actually leaves your outbox, and that only works if you catch it inside your own webmail or app session. Outlook's recall feature can pull back a message only if the recipient is on the same Exchange organization and has not yet opened it; it does nothing once they read the email or use an external provider like Gmail. Once either window closes, recall is no longer possible.

Should you tell the recipient even if the email seems harmless?

Yes. The recipient has no way to know it was harmless without you telling them, and staying quiet reads worse than a small mistake ever does.

How do you find which permission let the agent send the email?

Pull the agent's action log or tool-call history around the timestamp of the send, identify the tool or integration that executed it, and check what scope it was granted. Look specifically for whether "send" was bundled into a broader permission, such as full inbox access, rather than granted as its own narrowly scoped action.

What's the difference between this and an AI coding agent deleting production data?

Both follow the same pattern, contain, disclose, and audit the trigger, but the audience differs. A deleted database is an internal incident you can often resolve without anyone outside your company knowing. An unauthorized email has already reached an external recipient the moment it sends, which is why disclosure to that person is not optional the way it can feel optional with a purely internal incident.

Does this apply to Slack messages or other outbound tools, not just email?

Yes. The same checklist and approval-gate framework apply to any agent action that reaches someone outside your immediate control, including Slack messages to external channels, calendar invites, or support replies. Email is simply the most common version of this failure mode.

If you're building the sending capability yourself rather than reacting to an agent's mistake, see how to add email sending to an AI built app for the approval-gate pattern from the start.