Guardrails for autonomous sending
An agent that can send email can also send the wrong email to everyone you have. The controls that survive that moment are the ones running on a server the agent does not get to reason with.
Five controls, in the order they save you · all of them enforced outside the prompt
1. Scopes narrower than the account
A full-access key is convenient for exactly one afternoon. Give the credential the areas the job needs and nothing more, so the blast radius of a bad decision is the size of the task rather than the size of the account.
# a key that can send transactional email and read usage, nothing else
email:send
usage:read
# NOT this, unless you mean it
*When the agent acts for a user rather than for you, the permissions come from what that user approved on the consent screen, and they stay editable afterwards without reconnecting the client.
2. A cap that is a number, not a hope
Per credential, per day: how many messages, and how much spend. A cap is what turns a runaway loop into a failed call with an error code. Sending applies these to MCP tools and answers with a refusal rather than a partial send, which is the behaviour you want at three in the morning.
3. Idempotency, required rather than offered
{
"from": "Acme <[email protected]>",
"to": "[email protected]",
"subject": "Your order shipped",
"html": "<p>On its way.</p>",
"idempotencyKey": "order-4182-shipped"
}The key describes the event, not the attempt: order 4182 shipped, welcome for user 91, invoice 7 reminder. Derived that way, a retry is recognised and answered with the original message id. Derived from a timestamp or a random value, it protects nothing and you will discover that from a customer.
4. Rules the agent cannot opt out of
Sending is refused from a domain that is not verified. Addresses on the suppression list are dropped, and a suppressed primary recipient stops the send with a distinct error. Neither can be overridden with a flag, because a flag is exactly what an agent would set when it decides the send is important enough.
5. An audit log, so the question has an answer
Every tool call is recorded with the credential that made it. When someone asks why a customer got that email, you want a log of what was called, not a reconstruction from the model's transcript. The per-contact view answers the other half: sent, delivered, skipped, and the reason it was skipped.
Where to put the human
At the points of no return: activating an automation, enrolling a list of contacts into a live flow, sending a campaign. Those are the calls that turn a draft into thousands of real messages, and they are worth a confirmation with the real number in front of it. Everything else belongs to the caps, which do not get tired.
All 71 of our MCP tools run inside these controls, including the ones an agent reaches for when it is trying to be helpful.
Questions
Why is a system prompt not a guardrail?
Because it is an input to a model, and inputs can be overridden by other inputs. An email in an inbox, a web page, a file it was told to read: all of them are text arriving at the same place as your instructions. A control that lives in the prompt is a suggestion with good intentions.
What is the minimum set worth having?
Scopes narrower than the account, a spend or volume cap per credential, idempotency on anything that costs money, and an audit log. Everything else is refinement.
How does idempotency help with an agent specifically?
Agents retry. They retry after a timeout they misread, after an error they recovered from, and after a user says try again. A required idempotency key turns all of that into one send instead of four, and it costs you one field.
What about a human in the loop?
Right for anything irreversible and expensive: activating an automation, enrolling a list into a live flow, sending a campaign. Wrong as the only control, because approval fatigue is real and the tenth dialog gets clicked without reading. Use it for the point of no return, and caps for everything else.
Other guides
Email MCP servers compared
Eight providers, what their MCP server actually exposes, and which one to pick for the job you have.
Choosing an email API for AI agents
The six questions that decide this, and the answers that disqualify a provider outright.
How to give an AI agent its own email inbox
From no address to a threaded reply, with the code, in about ten minutes.
Multichannel messaging for AI agents
Email, WhatsApp and Telegram from one flow: consent, fallback and what it costs to get it wrong.
