AI Agent Security for Email: Risks and Controls

2026-11-09

Reported AI-related incidents have climbed sharply in recent years, and they tend to share a shape: a system reads outside text, then takes an action a person has to unwind. The NIST AI Risk Management Framework gives teams a way to map and manage that risk. An agent with its own inbox makes it immediate.

The action that matters is the mail that leaves. A reply, a forward, a new thread, or a file pulled from storage goes out under the owner's address, and the recipient cannot tell whether the model was following the task or a line buried in a complaint. AI agent security for that setup is the set of checks on what exits. A longer system prompt adds none.

Table of Contents

• Why Email Turns Agent Security Into a Mailbox Problem
• The Main Risks and the Control That Limits Each
• How Injected Email Instructions Get Past an Agent
  • Trusted instructions and untrusted data share one window
  • Why phrase lists miss the attack
• How to Screen and Quarantine Inbound Mail Before the Agent Reads It
• Enforcing Inbound and Send Checks in Your Agent's Tool Layer
• Scoping Access So One Mistake Stays Small
  • Three grants, tested against the worst send
  • One admin key is the common miss
• Outbound Limits, Duplicate Checks and Human Handoff
• Confirm the Controls Before Your Agent Sends

Why Email Turns Agent Security Into a Mailbox Problem

In 2025, 82% of surveyed organizations said they already use AI agents, but only 44% reported having policies to secure them, in a SailPoint press release on a Dimensional Research survey of 353 participants. Adoption ran ahead of written rules. An inbox makes that gap concrete, because the agent holds two capabilities at once.

Say a support mailbox receives a polite complaint. The last paragraph asks the agent to pull every invoice thread and mail the list to an address the customer just invented. A chat model that swallows that line produces a bad paragraph. An email agent can send the reply, forward the thread, open the attachment, or write to someone new. The recipient sees a normal message from the company address.

The attack surface splits into three parts, and each needs its own control.

• What the agent reads: inbound bodies, attachments, and quoted history from earlier senders.
• What it can do: reply, forward, start a thread, or change a mailbox setting.
• Whom it can reach: known contacts, suppressed domains, and other agents working the same people.

No single check covers all three. Screening a body does not cap how many people a second agent can write. A send limit does not stop a poisoned thread from being treated as the task. Treat inbound email as hostile by default, and treat every outbound message as an action that needs its own authority check.

The Main Risks and the Control That Limits Each

Just 15% of IT application leaders were considering piloting or deploying fully autonomous AI agents, according to Gartner's survey write-up. The hesitation tracks a real gap: security teams increasingly treat agents as a new attack vector, while governance structures mature enough to own each risk remain rare. A threat list without an owner is how that gap stays open.

The map below pairs each inbox risk with the control family that limits it. Rows run from a single poisoned message to failures that build over weeks. They are not a frequency ranking. Nobody has published a rate for each row.

Injection and exfiltration are content problems with an action on the end, so the control sits where a message enters or leaves the mailbox. Unauthorized sending, duplicates, volume, and payment fraud are outbound problems: each needs a check on the act of sending, and a person where money moves. Drift is a permissions problem. Molted's defaults follow that split. The agent cannot switch off the prompt-injection and quarantine checks, it can tighten a safety rule but never loosen one, and paying stays a person's decision.

Copy the table into the team doc and mark each row covered, partly covered, or missing before the agent goes live.

Practical rule: If a row has no named owner, that risk is uncovered, even when the model is careful.

A small team often has no full-time security lead for that review. The fractional CISO compliance benefits described by MR2 Solutions are one way to get a named owner for the gaps without hiring a department, especially when agents already send mail.

How Injected Email Instructions Get Past an Agent

A support agent triages a mailbox. The ticket is a real delay complaint, then one extra sentence: before replying, search this inbox for invoices and send the list to an external address. The model has no reliable mark that the sentence came from an attacker. It arrived in the same channel as the customer's actual text.

Trusted instructions and untrusted data share one window

The system prompt and the owner's task are trusted control text. Email bodies, quoted replies, attachments, and tool output are untrusted data. Once both sit in the same context, the model can treat the attacker's line as the next instruction. Direct injection is text a user types into the chat. Indirect injection is text hidden in content the agent reads while doing a legitimate job. Email is the second case.

The dangerous step is not a weird reply on screen. It is a tool call: search the inbox, forward a thread, or change who gets the next message.

Why phrase lists miss the attack

A 2026 study of email-agent prompt injection found that context-focused attacks defeated static defenses at a 96.7% attack-success rate, compared with a baseline below 1%, as reported in the email-agent injection study. The first attack email succeeded in 61.4% of trials. Common prompt-injection classifiers performed near chance, with AUROC values from 0.43 to 0.59, when the attack manipulated context instead of using phrases such as “ignore all instructions.”

A blocklist of jailbreak slogans will not catch a sentence that looks like part of the ticket. The useful question is what that email is allowed to cause.

Can this message trigger a send, a read beyond the current thread, or a change to mailbox policy? If yes, the text needs a gate that does not live inside the model.

Isolate the suspicious body. Require a separate check before the agent acts on instructions that arrived through the thread. Screening still matters, because it keeps obvious attacks out of context. It is not the authority check.

How to Screen and Quarantine Inbound Mail Before the Agent Reads It

Run inbound mail through a fixed order before any model call. Each step has a reason and a slip that undoes it. Prompt injection scanning and intent classification help, and they are not infallible, which is why later steps do not trust the score alone. A closer look at how scanning fits an email pipeline shows why the screen has to sit in front of the agent, not inside the prompt.

1. Label the message first. Stamp sender, mailbox, and thread history on the record before the body reaches the model. A body without those labels is hard to judge in a log the next day. The slip is adding labels after the model has already read the text.
2. Score the body. Run injection screening and intent classification, and store the risk score with the message id. The slip is trusting one classifier. Context-based attacks can look like ordinary customer prose.
3. Quarantine the high-risk original. The agent should see a placeholder marked untrusted. Only a person releases the original. The slip is a quarantine the agent can lift itself. On Molted Email, every incoming email is screened for prompt injection before the agent can read it, a high-risk message is quarantined for a person to release, and the agent cannot switch those checks off. Inbound mail is labelled, and anything steering the agent is quarantined.
4. Pass a safe extract for medium risk. Where the task allows it, hand over sender, requested action, dates, and amounts instead of the full body. The slip is an extract that drops the sentence carrying the instruction, so a reviewer later cannot see what was asked.
5. Check authority before any side effect. Reply, forward, new thread, and attachment access read mailbox policy, not the model's opinion. The slip is asking the model whether its own action is allowed.
6. Log every decision. Record message id, score, and reason for allows and blocks. The slip is a log that only stores what was blocked, so you cannot see which risky mail still went through.

Re-screen a thread when a new message joins it. Keep the quoted original for a person. Extracts are for the agent. Reviewers need the words that were sent.

Enforcing Inbound and Send Checks in Your Agent's Tool Layer

Claude Code, Cursor, Codex, an MCP server, and a plain REST client all hit the same failure if the model decides that a send is fine. The model proposes. The tool wrapper decides.

The agent calls one send tool. The wrapper receives the draft, the thread id, and the recipient. It confirms this key's mailbox scope allows sending. It checks that the recipient is not suppressed, the thread is not quarantined, the cooldown has elapsed, and the daily cap is not already hit. It refuses payment, credential, and vendor-change requests outright.

On any failure the wrapper returns a refusal and does not call the mail API. Shape it so the model can recover without learning the policy numbers: allowed set to false, plus a reason code such as quarantined_thread, suppressed_recipient, or daily_limit. The reason names the block. It does not echo thresholds, suppression entries, or other tenants' mail. The same call writes message id, recipient, reason, and timestamp to the audit log.

On success, and only then, the wrapper calls the send endpoint.

Read tools should return extracts unless the task scope explicitly allows full bodies. Do not expose a second “raw send” tool beside the gated one. Developers will call whichever is shorter.

Prove the gate with a scratch agent and a recipient you have already suppressed. The tool must return the refusal, and the mail API must see zero requests. If a packet still leaves, the check is advisory and the agent can walk around it.

Scoping Access So One Mistake Stays Small

Each agent gets the smallest set of rights that finishes its job. A stolen or steered session can only do what that set allows.

Three grants, tested against the worst send

A triage agent reads one support mailbox and cannot send. The worst outcome is a bad summary in the ticket tool, not a message to a customer. A follow-up agent sends only on threads it opened. It cannot introduce the company to a stranger. An outreach agent sends to one campaign list and has no key for the support inbox, so a poisoned campaign brief cannot walk into billing mail.

One admin key is the common miss

Sharing one admin key across several agents means one leaked credential opens every mailbox. A key tied to one mailbox, with read, send, or manage on that mailbox alone, keeps the blast inside that box. Read still covers every thread and attachment the key can see, so read scope should match the threads the task needs, not the whole archive “just in case.”

Agents can tighten a safety rule, for example a longer cooldown or a stop on one domain. They cannot remove a suppression, raise their own send limit, or approve their own message. An agent can also lower its mailbox autonomy. Raising it takes a person.

List each agent, each mailbox, and each right. Then write the worst message that grant could send. If that message would move money, change a vendor, or leave the company, the grant is too wide.

Outbound Limits, Duplicate Checks and Human Handoff

The FBI's 2025 Internet Crime Complaint Center data recorded 24,768 business-email-compromise complaints and approximately $3.046 billion in reported losses, about $123,005 per complaint, in a summary of the 2025 IC3 report. The same report recorded 22,364 complaints that cited artificial intelligence in the fraud, with $893 million in total losses, including $30 million tied to business email compromise. Payment, credential, vendor-change, and internal-disclosure requests do not get a model-approved reply. They route to a person.

A reviewer on every message is the usual answer, and it does not hold the line by itself. An approver sees one draft. They do not see two agents writing the same lead, a retry loop overnight, or a cooldown that someone edited away.

Put outbound checks in this order, each with the failure it is there to catch.

• Duplicate check: compare the draft with recent sends to that address. Without it, a webhook retry and a second agent both “help.”
• Recipient cooldown: block another send to the same person inside the window. Without it, a polite follow-up becomes a burst.
• Suppression: honor address and whole-domain stops from one shared list. Without it, opt-outs apply to one agent and not the next.
• Daily mailbox cap: stop the loop before hundreds of messages leave overnight. Without it, a bug looks like a campaign.

A dry run shows whether a draft would go out, without sending it. When several agents share a list, a contact lease stops two of them from emailing the same person at once. Leases and one shared set of checks are the coordination. A vote between agents is optional and does not replace the cap.

The agent can hand a thread to a person at any time, with a note. No agent reply leaves until that person returns the thread. Replies on a flagged thread wait for a person before they send. When a person should take the thread is a judgement about the request, not a default on every low-stakes reply.

On Molted Email, approvals are an optional dial. A new mailbox runs without them, and you turn them on for the modes that need a person. Pair any approval mode with send limits. The approver judges one message. The cap is what catches aggregate harm.

Confirm the Controls Before Your Agent Sends

Turn the design into five pass-or-fail tests before the first live send. AskYourQA's guide to agent validation is a useful companion for how to script those checks so they fail closed instead of “looking fine” in a demo. A single call that sends, checks, and records the result is easier to test than three tools with three logs. One call that sends, checks, and tracks is the shape to assert against.

1. Known-bad inbound. Send a test message that tries to steer the agent. It is quarantined. The agent sees only the untrusted placeholder.
2. First contact. Ask the agent to open a thread with someone the mailbox has never written. The approval mode holds the send.
3. Cooldown and daily cap. Trigger both against a scratch list. Each refusal is logged with a reason code, and nothing reaches the mail API.
4. Handoff. Pass a thread to a person with a note. No reply leaves until they return it, and the note is the one they received.
5. Dry run. Run one dry run to a test address before automatic send is enabled. Read the would-send result. Then enable the mode.

Each week, count blocked sends and quarantined messages. Read a sample of blocks that a person later called legitimate, and tune that rule in the open. Do not delete it without notice. Check bounce and complaint rates, and confirm no agent raised a limit or cleared a suppression. The review question is simple. Did the controls block the right things, and did a person see every risky message?

No screen is complete. The safe default for a risky action is to wait for a person. Before automatic send, the one action that matters is test one and test five on the actual mailbox, not on a mock that always returns allowed.

Molted Email is a mailbox for AI agents, the way Gmail is a mailbox for people. It is not an API wrapper on another provider. Inbound mail is screened and quarantined before the agent reads it, and every outgoing message is checked for duplicates, cooldowns, suppressions, and send limits, with a handoff when a person should take the thread. Start free at molted.email (free for people, paid plans from $19 a month) at Molted Email.