What an AI Agent Should Never Be Allowed to Email

An agent that drafts email is useful. An agent that sends email is a different kind of tool, because email leaves the building and cannot be recalled.

The rule for AI agent email is easier to hold than a long policy: an agent should never send unreviewed mail to anyone outside the company, and never send anything containing a price, a promise, a legal position or a decision about a person. Everything else is a judgement call. Those are not.

Block by recipient

Some recipients make any message high stakes regardless of content.

• Regulators and government bodies. Correspondence with a regulator is a record and often a legal act. Timing, wording and who signs it all matter.
• Job candidates. A rejection, an offer, a schedule change. These carry employment law weight in most places, and they land on a person having one of the more stressful weeks of their year.
• Anyone in a live dispute. Once a matter is contentious, every message is potential evidence and may be read by lawyers.
• Journalists and analysts. No explanation needed.
• Customers cancelling, complaining or asking about a refund. The moment someone is unhappy is the moment a slightly off message becomes a screenshot.
• Large distribution lists. Not because the content is risky but because the blast radius is. A mistake to one person is a correction. The same mistake to four thousand is an incident.

Block by content

The other half of the list is about what is in the message, whoever it goes to.

• Anything with a number attached to money. Prices, quotes, discounts, invoices, refunds, salary figures. A wrong number in writing is often treated as binding, and arguing otherwise costs more than the error.
• Anything that reads as a commitment. Delivery dates, scope, service levels, "we will". An agent has no way of knowing whether the business can actually do the thing.
• Anything about a person's employment. Performance, discipline, leave decisions, changes to terms.
• Anything that states a legal or compliance position. Whether something is permitted, whether the company is liable, what a contract means.
• Anything containing another party's confidential data. Especially where the agent has assembled it from several sources and nobody has checked what ended up in the summary.
• Apologies that admit fault. An apology is fine. An admission of cause is a decision, usually one for a lawyer or an executive.

Why sending is the hard line

Most agent actions are reversible with effort. A record can be corrected, a task reassigned, a document redrafted. A sent email is gone. The recipient has already read it, already forwarded it, already formed a view.

That asymmetry is the whole argument. It is why a draft-and-approve pattern costs so little and a send-directly pattern can cost a great deal on any single bad day. Which shape of draft and approve to use is a choice between a few approval patterns that hold up under regulation.

What is safe to let through

The blocklist is long, so it is worth saying what remains, because it is more than it looks.

Internal notifications. Status updates that repeat facts already in a shared record. Meeting logistics. Reminders that a form is overdue. Replies that consist entirely of a link to existing documentation. Acknowledgements that say a request has been received and someone will respond.

The pattern is that safe messages contain no new commitment and no new judgement. They move information that already exists to someone who already has a right to it.

Making the list enforceable

A blocklist that lives in a policy document gets ignored. It needs to sit where the send happens.

Three checks that are worth building:

• Recipient domain check. Anything outside your own domains routes to a person.
• Content pattern check. Currency symbols, dates framed as deadlines, phrases like "we will", "we agree", "you are entitled". Pattern matching is crude and it catches the obvious cases, which are most of them.
• Volume check. Above a threshold of recipients, always a human, even for internal mail.

None of these are clever. Clever is not the point. The point is that the rule fires without anyone having to remember it, which you prove by testing the agent before it touches live records.

Where the human sits

In SicherOne, agent output is approved by a human before it ships, which is the mechanism the whole blocklist depends on. The agent still does the work of drafting, gathering the context, checking the record. What it does not do is decide that the message is ready.

The question worth asking your own team is not whether you trust the agent. It is which mistakes you can undo before lunch, and which ones you will still be explaining in a month. Send that second list to the approval queue and leave it there, with a named owner rather than a team inbox waiting at the other end.