Keeping an autonomous agent from becoming a spam problem

Nobody sets out to build a spam bot. They build a helpful agent, give it an address, and discover that helpfulness at machine speed looks exactly like spam from the outside. This is the set of controls that keeps an autonomous agent useful without letting it damage your domain, your customers, or your legal position.

22 July 2026 · 6 min read

Prompts are not controls#

"Do not send unsolicited email" is a preference. It survives exactly as long as the context that contains it, and it competes with every other instruction the model is balancing, including the goal you actually gave it. A model that has been told to book five meetings this week will find a reading of your instructions that permits contacting people.

Controls have to live under the tool, where the model cannot argue with them. Everything below is either enforced by infrastructure or backed by something that is.

Control one: every send is classified, and cold ones are watched#

A reply goes to someone who wrote to you first in that thread, so it carries no unsolicited-contact risk. Anything else is a cold send, and that is the operation that can go wrong. MCPmailer classifies each one, attaches an unsubscribe link, and watches it with two tripwires: duplicate content, which catches the same message going to many people, and velocity, which catches a sudden burst. Both kinds of send draw down one daily allowance, 100 a day on Free and uncapped on paid plans, and one monthly allowance.

The practical effect is that a support or invoice chasing agent runs at full speed forever, while an outreach agent hits tripwires it cannot talk its way past. A refused send returns a reason such as daily_send_quota_exhausted with a reset time, so the agent can handle it: ask a human, wait, or do something else.

Control two: approval where it matters, and only there#

Some sends deserve a person: new outreach from a workspace that has not been claimed, anything going to a domain you have never contacted, a message the agent itself flags as unusual. Keep the gate narrow. If everything needs a click, the reviewer becomes a rubber stamp within a week and the control stops meaning anything.

A review queue that is always full is not oversight. It is a queue.

A useful test: if you cannot describe, in one sentence, what a reviewer is checking for, the item should not be in the queue. Designing the queue itself, and knowing when to remove it, is in approval a human will still read.

Control three: scope per agent#

Give each agent its own identity and its own key. One agent cannot read another's inbox, send from another's address, or reach notes and vault secrets it was not granted. When something goes wrong the blast radius is one agent, and revocation is one key rather than a rotation across your whole stack.

Inbound deserves the same treatment. Per-identity mail rules run in blacklist mode by default, where everything arrives except blocked senders, or whitelist mode, where only allowed senders do. An exact-address rule overrides a domain rule, so you can allow a partner domain and still block one address inside it. For an agent that only ever talks to known counterparties, such as a recruiting coordinator, whitelist mode is the right default. Rules are covered in identities.

Control four: an audit trail with a reader#

Every message in and out is recorded against an identity, with the thread it belongs to and the key that sent it. That matters for the obvious compliance reasons, but the everyday value is different: it is how you notice that your agent has started answering a question wrongly, forty messages before a customer tells you.

Make someone responsible for looking. A weekly ten minute pass over sent mail catches drift that no automated check will flag, because the failure is usually "technically correct and completely unhelpful". Sample five threads, read them end to end, and ask whether you would have sent the same replies.

Control five: hard structural limits#

• Five recipients per message, maximum. Bulk email is a different product and should be one.
• Rate limits per key, so a runaway loop costs time rather than reputation.
• Automatic suppression after a hard bounce or a complaint.
• A monthly spend cap, so a loop that discovers it can send is bounded in money as well as in volume. See what email actually costs.
• Domain separation, so agent behaviour cannot take your primary domain down with it.
• Refusals that carry a machine-readable reason, so the agent adapts instead of hammering.

None of these depend on the agent behaving well, which is the point. Good behaviour is what you hope for; limits are what you rely on. The deliverability consequences of ignoring them are in deliverability for agent senders.

The legal floor, briefly#

Not legal advice, but the shape of the obligations is stable and worth knowing before an agent sends anything cold.

The obligations in full, including retention and deletion, are in the compliance floor for agent email. Two agent-specific notes. Automation does not create a new exemption: an agent sending on your behalf is you sending. And an opt-out has to be honoured by your infrastructure, not by an agent remembering, which means suppression at the account level the moment someone asks.

Control six: make it obvious what is on the other end#

An agent that identifies itself does better than one that does not, and the failure mode of concealment is severe: a recipient who discovers mid-thread that they have been writing to software feels tricked, and says so publicly more often than you would like.

There is no need for a disclaimer paragraph. A sending name that reads as an assistant, an address on an agents subdomain, and a fast path to a person are enough. Keep the option to reach a human one sentence away and most people are perfectly happy.

What good looks like#

A healthy agent email deployment is boring. Reply volume is high and steady, cold volume is low and deliberate, bounces are near zero because the addresses came from real conversations, and complaints do not happen because nobody is being contacted who did not expect it. When you open the dashboard, nothing surprises you.

If you are setting this up for the first time, the quickstart gets an identity running, and the use case pages show what the safe versions of each job look like.

Questions#

How do I stop an AI agent from sending unwanted email?

Enforce it below the model: quota-gate first contact, cap recipients per message, require approval for new outreach, and scope each agent to its own identity and key. Prompt instructions alone are not a control.

Should every agent send need human approval?

No. Approval on everything turns into rubber stamping within a week. Reserve it for new outreach and unusual sends, and let thread replies flow.

Can I stop specific senders from reaching my agent?

Yes. Per-identity mail rules run in blacklist or whitelist mode, and an exact-address rule overrides a domain rule. See identities.

What happens after a bounce or a complaint?

The address is suppressed automatically and further sends to it are refused, so enforcement does not depend on the agent remembering. Your system can also react to the webhook.

Do email laws apply to messages an agent sends?

Yes. An agent sending on your behalf is you sending, and CAN-SPAM, GDPR and PECR, and CASL apply exactly as they would otherwise. Opt-outs must be enforced by infrastructure rather than by a prompt.

Does the agent have to say it is an agent?

Rules vary by jurisdiction and are tightening, but the practical answer is yes: an identifiable assistant with a fast path to a person performs better and avoids the worst reaction, which is a recipient discovering it mid-thread.