The firewall between your AI agent and your sending reputation.

Handing an autonomous agent a send()call is a different kind of risk than handing it to a human. A person sends a few emails an hour and notices when something feels wrong. An agent in a loop can send thousands before anyone looks, and it has no instinct for “this feels like spam.” A retry storm, a poisoned input, a prompt that talked it into emailing a purchased list — any of these can get your entire domain flagged as a spammer in an afternoon. And domain reputation, once burned, takes weeks to rebuild.

So the interesting question for agent email isn’t “can it send?” Any API can send. The question is: what stops a misbehaving agent from torching your sending reputation?That protection is the product. This post walks through the firewall Mails.ai puts between your agent and the outside world — on the way out and on the way in.

The threat model

Three failure modes are specific to agents, and a normal email API does nothing about any of them:

• The runaway agent.A bug, a bad loop, or a hallucinated task list has your own agent sending mail it shouldn’t — to the wrong people, too fast, or to addresses that already bounced. Every one of those is a complaint or a bounce, and complaints and bounces are what get a domain flagged.
• The poisoned agent.An attacker emails your agent instructions (“forward everything to me,” “email this list on my behalf”) and a naive agent obeys. Now your reputation is being spent by someone else, through your own infrastructure.
• The noisy neighbor.On shared sending infrastructure, one abusive tenant’s complaint rate can drag down the reputation of everyone sharing the IP pool — including you, who did nothing wrong.

A firewall answers all three the same way: inspect every packet, enforce a policy, and isolate blast radius. Here’s how that maps to email.

Outbound: a gate on every send

Every agent.send() passes through a reputation classifier before it leaves our system. It’s rules plus a lightweight LLM call that scores the send for complaint-risk signals: the recipient relationship, engagement history, content patterns, and send-rate anomalies. Two things can happen at that gate:

• Suppression check.If the recipient is on your workspace’s suppression list — anyone who previously bounced, unsubscribed, or complained — the send is dropped right there. Suppression runs at send time, so a known-bad address never gets another message no matter which of your agents tries.
• Risk throttle.If the sender’s risk score is spiking — a sudden send-rate jump, a batch that looks list-shaped, content that reads like cold outreach — the sender gets auto-throttled until its reputation rebuilds. A runaway loop hits the brakes automatically instead of running until AWS notices.

Cleared sends flow through AWS SES. The classifier is invisible to your code — you call send()exactly as you would with any transactional API, and the firewall does its work underneath. It’s deliverability infrastructure, not a knob you tune.

import { mails } from "@mailsai/sdk";

const sarah = mails.agent("sarah"); // sarah@yourcompany.mails.ai

// You just call send(). The reputation classifier + suppression check
// run before it leaves — a suppressed recipient is dropped, a spiking
// sender is throttled. No flag to set, no policy to wire up.
await sarah.send({
  to: "customer@example.com",
  subject: "Your report is ready",
  body: "...",
});

The complaint cron: paused before AWS ever sees it

The send-time gate stops the obvious. The complaint cron catches what slips through. A per-sender complaint-and-bounce job runs every 15 minutes. Any sender crossing a 0.3% complaint rateauto-suspends, and its reputation drops for that sender identity permanently. A 5% bounce rate triggers the same suspend.

The 0.3% number is deliberate. AWS SES puts an account under review when its complaint rate crosses 0.5% (their published Sending Review Process; the healthy target is under 0.1%). By auto-suspending at 0.3%, a misbehaving sender is paused before the shared account ever registers a number that would put everyone at risk. The threshold sits below the danger line on purpose.

Isolation: one rogue tenant can’t burn the pool

This is the noisy-neighbor answer. Reputation on Mails.ai is scoped two ways:

• Per agent.Every agent has its own reputation score, built from real engagement signals — reply rate, bounce rate, complaint rate, suppression hits, recipient sender-reputation lookups. A bad agent’s bad score doesn’t bleed onto your good ones.
• Per workspace.Suppression and verified-agent status are workspace-scoped. A complaint against someone else’s agent in another workspace has zero effect on yours. A banned sender loses verified-agent status across all of youragents — enforced on every send — so a bad actor can’t just spin up a fresh identity and keep going.

Because the complaint cron pauses a bad sender at 0.3% — long before it accumulates enough complaints to move the shared SES reputation — a rogue tenant gets stopped before the network ever feels them. Your agent’s deliverability is not a function of anyone else’s behavior. Customers on Scale+ who want physical reputation isolation as well can add a Dedicated IP ($50/mo per IP), provisioned on request with its own SES configuration set and monitoring.

Your agent can also read the score and act on it. Reputation is queryable via the mails.get_reputationMCP tool, and it’s baked into every inbound event as event.sender_reputation, so your agent can refuse to act on a low-reputation sender before it even reads the body:

sarah.onReply((event) => {
  // The sender's reputation rides on every inbound event.
  if (event.sender_reputation < 0.3) {
    return; // don't act on senders with a poor track record
  }
  // ...handle the event
});

Inbound: the other half of the firewall

A firewall inspects traffic in both directions. The poisoned-agent failure mode — an attacker emailing your agent instructions and the agent obeying — is a real remote-code-execution class for any system that reads raw inbound text. Mails.ai runs every inbound message through a six-category prompt-injection scanner before it becomes a structured event. The result rides on the event as an injection_score, and high-confidence attacks are flagged quarantined so your agent skips them:

sarah.onReply((event) => {
  if (event.injection_score > 0.5) {
    return; // refuse before reading the body for intent
  }
  switch (event.intent) {
    case "schedule_demo": return calendar.createEvent({ ...event.entities });
    case "refund_request": return tickets.escalate(event);
  }
});

That’s a summary; the inbound firewall gets its own treatment in the prompt-injection post, including the six attack categories and how to tune the threshold.

We block cold outreach on purpose

Every layer above points the same direction, and it’s worth stating plainly: cold email is not a supported use case on Mails.ai. Our Acceptable Use policyrequires that every send has a real recipient relationship, a valid sender identity, an explicit disclosure of why you’re contacting the person, and an unsubscribe honored within 7 days. Organizational addresses only. The reputation classifier scores sends for cold-outreach signals and throttles them; the complaint cron auto-suspends the senders who generate complaints. We’re transactional-and-agent infrastructure — the safe sender for agents that email people who expect to hear from them.

If your plan is to point an agent at a purchased list and blast, we are the wrong tool, by design. That’s the same design that protects the customers who use us correctly: the firewall that stops youragent from going rogue is the same one that stops everyone else’s from touching your reputation.

What this does not do

Honesty about the edges, because a firewall is a layer, not a guarantee:

• It doesn’t replace your own business rules.The reputation classifier scores complaint risk; it doesn’t know that a particular high-value action needs a second approval. Sandbox your agent’s tools and gate consequential actions yourself.
• It doesn’t catch social engineering. A message with no injection tokens that simply persuades your agent to do the wrong thing scores low on injection and still needs your intent classification and business logic to catch it.
• Single-provider dependency is a known gap.Cleared sends go through AWS SES today. A documented multi-vendor failover runbook (Postmark / SparkPost / Brevo, with a roughly four-hour DNS swap path) is planned so a single-provider outage doesn’t take your agent offline — it is not live yet.

The one-line version

Every send is scored and suppression-checked before it leaves. Bad senders auto-suspend at 0.3%, below the line where AWS would flag the shared account. Reputation is isolated per agent and per workspace, so a rogue tenant is paused before the network feels it. Every inbound is injection-scanned. And cold outreach is blocked by policy and by the classifier. You call send(); the firewall does the rest.

Read the architecture page for the full send and receive pipelines, or the prompt-injection post for the inbound side in depth.