How to let an AI agent send email safely

Why sending email is a high-impact action#

Most things an AI assistant does can be checked before they matter: a draft can be reread, a summary ignored. A sent email cannot. Once a mail provider accepts a message it has taken responsibility for it, and nobody can reliably pull it back. It goes out under your name and your domain, often to people outside the organization, and every mistake counts against the domain's reputation with mailbox providers.

Two weaknesses of language-model agents make this sharper:

• Excessive agency. OWASP's Top 10 for LLM applications lists it as LLM06: an agent given more functionality, permissions or autonomy than its task needs can do damage when it misunderstands or is misled. A connector that can "send any email from this mailbox" when the job is "draft replies to support tickets" is a textbook case.
• Prompt injection. Text the agent reads (an incoming email it was asked to summarize, a web page, a document) can carry instructions. If the agent can send email, an injected instruction can try to make it send something, to someone, with data it has seen.

Neither problem is solved by asking the model nicely. The controls below put the decision somewhere the model cannot reach.

Five controls to have before an agent sends#

1. A named identity and an owner#

Each agent should be its own identity, not a person's account. It needs a name people recognize, a person accountable for it, and a credential of its own that can be revoked without changing anyone's password.

What to look for: agents listed by name; an owner on each; per-agent credentials; the agent acting with the owner's permissions at most, never more.

In SecureThread an agent has a name, an owner and a status (Active, Paused or Revoked). Its sends go only from mailboxes its owner may use, and assistants connect with OAuth 2.1, so there is no password to share.

2. Least privilege#

Decide what the agent's job needs and grant only that.

• Mailboxes: which addresses may it send from? An agent drafting sales follow-ups does not need the finance mailbox.
• Templates: may it write freely, or only fill in approved templates?
• Recipients: an allow list of domains or addresses, or only people inside the organization.
• Volume: a daily limit that fits the task, so a loop cannot send a thousand messages.
• Actions: reading, drafting and sending are different rights. Grant them separately.

SecureThread's agent policy covers allowed recipients (up to 200 domains and addresses), a daily send limit, permitted mailboxes and templates, and a published-template requirement. A policy can only narrow the organization's rules, never widen them.

3. Autonomy you can turn up slowly#

Agents should start with the least autonomy and earn more:

These are SecureThread's four modes, and a new agent starts at "Every send needs approval". Whatever tool you use, make sure the most autonomous setting still runs inside rules the agent cannot change.

4. Rules on the server, with reasons shown#

A rule written into the agent's prompt is a suggestion. A rule enforced by the system the agent calls is a control. Every request to send should be checked, at the moment it is made, against:

• the person's current permissions (a role change should apply on the next request);
• the agent's access levels and policy;
• the organization's sending rules and content checks.

When a send needs a person, the approver should see why. Useful risk signals include recipients outside the organization, contact groups, attachments, a mailbox the person does not own, content the agent wrote itself rather than an approved template, and links that hide where they go (shortened links, bare IP addresses, link text that shows a different site). SecureThread lists each of these reasons on the approval page.

Automatic sending, if you allow it at all, should be the narrowest case. SecureThread's is off by default; when an administrator turns it on, an email goes without approval only if it comes from the current published version of a reviewed shared template, the agent wrote no wording of its own, it goes from the person's own mailbox with no attachments or contact groups, and it stays within a recipient cap (1 to 50, default 1) and, by default, inside the organization.

5. A record and a pause switch#

You will need to answer "what did the agent do, and who allowed it?" Keep a record of each send request, the decision and who made it, what was queued or sent, and every refusal with its reason, without storing message bodies where metadata will do. Be able to stop an agent at once, and to revoke it for good.

In SecureThread each agent has an activity list of its requests, outcomes and refusals; pausing refuses every request until someone resumes it, and revoking is permanent. See what an email audit trail should record.

A risk worksheet you can fill in#

Before connecting an agent, write one row per thing it will do:

Revisit the table after a few weeks of real use: the activity record will show which requests were always approved unchanged (candidates for more autonomy) and which were declined (candidates for tighter rules).

Questions to ask any tool that connects agents to email#

1. Does the agent get its own identity and credential, or does it act with a person's mailbox token?
2. Can I limit mailboxes, recipients, templates and daily volume per agent?
3. Is approval the default, and is the approval tied to the exact message the agent prepared?
4. Are rules enforced by the service on every request, or only described to the model?
5. What does the approver see about why a send was held?
6. Can I pause or revoke an agent instantly, and is that recorded?
7. Does the record show requests, decisions and refusals without keeping message bodies it does not need?

Where SecureThread fits#

SecureThread connects assistants such as Claude, ChatGPT, Cursor and VS Code to your existing Google Workspace, Microsoft 365 and SMTP mailboxes through an MCP server, and applies the controls above on the server. Read the overview of AI email governance, or the setup guide for connecting an assistant.