Where the mail actually goes: data flow for an agent inbox
Somebody in procurement will eventually ask where the data goes. The honest answer for an email agent has three parts, and only one of them is about the email provider. Most teams can answer that one and stall on the other two.
5 min read
The three legs of the journey
Leg one: the mail itself. Inbound messages arrive, are stored, and are served to your agent. Outbound messages are accepted, signed, and handed to the sending infrastructure. This is the part your email provider processes, and the authoritative list of who touches it is a sub-processor list, not a sentence in a sales deck. Ours is at subprocessors, and the contract for processing on your behalf is the data processing addendum.
Leg two: the model. When your agent reads a thread and writes a reply, message content goes to whichever model provider you chose. That is your contract, your region selection, and your retention setting, not your email provider's. It is also, in most deployments, the leg carrying the most content and the one nobody documented.
Leg three: your own systems. The order lookup, the CRM write, the log line. Anything your agent touches to answer a question is part of the flow, and logs are where message content leaks most often, which is why the guidance in what to monitor in production is to log ids and actions rather than bodies.
Answer all three and the review is short. Answer one and it is not.
What we do and do not do with content
Two claims worth stating plainly, because they shape the rest.
We do not read message content, and we do not train on it. Abuse enforcement works from sending behaviour and metadata: volume, classification, bounce and complaint rates, the tripwires described in keeping an autonomous agent from becoming a spam problem. That is deliberate, because a system that needs to read bodies to enforce its rules is a system that has to keep reading them.
And we are not in leg two at all. No model provider appears in our sub-processor list, because your agent calls its model directly. That is a feature for you: it means your model choice, its region, and its retention policy stay decisions you make, and it means switching providers changes nothing about your email setup.
What procurement actually asks
| Question | Where the answer lives |
|---|---|
| Who processes message content? | The sub-processor list, plus your model provider |
| Where is it stored? | The sub-processor list, per processor |
| Is it used for training? | Not by us. Check your model provider's terms |
| How long is it kept? | Your retention decision, plus each processor's |
| Can you delete it on request? | Your process across mailbox, contacts, and your own systems |
| Who can see it internally? | Your access controls, plus each processor's |
| What is the breach process? | Yours, with a 72 hour clock under GDPR |
The pattern: most of these are answered by decisions you make rather than by a vendor page. That is uncomfortable the first time and correct, because the alternative is a provider making retention decisions on your behalf.
Reducing the surface
Four moves that shrink the flow without changing what the agent can do.
Send less to the model. The full practice is in sending the model less than you think it needs. get_thread returns the conversation without quoted repetition, and extracting three fields from an attachment beats pushing a contract through a model repeatedly. Less content in leg two is less content to account for, and it is cheaper, per what email actually costs.
Keep bodies out of logs. Ids, actions, sources, refusal reasons. A log aggregator full of customer mail is a retention problem you did not intend to create and the most common finding in a security review.
Decide retention per category. Archive what is dealt with, set a period for attachments separately from message bodies, and treat "forever, because nobody implemented deletion" as the wrong answer, per the compliance floor.
Scope agents narrowly. An agent that cannot reach the recruiting inbox cannot leak it. Per-identity scope is a data protection control as much as a security one, which is one more argument for the model in running several agents in one workspace.
Regions, honestly
Region questions deserve precise answers rather than reassuring ones, so the right move is to read the current sub-processor list rather than a blog post: processors and their locations change, and a page that restates them goes stale silently. If you have a hard residency requirement, that is a conversation to have before you build rather than a checkbox to find later, and it is what the enterprise tier exists for.
The same applies to leg two. Several model providers offer regional processing and zero-retention options, and if residency matters to you, that selection is probably the most consequential one in the whole flow, because it is where the content volume is.
What to write down before the review
- A diagram of the three legs, with your model provider named.
- The sub-processor list, current, for the email leg.
- Your retention period per category, with who decided it.
- Your deletion procedure, tested end to end.
- What your logs contain, demonstrated rather than asserted.
- Your breach process, with the notification clock in it.
Half a day of work, and it converts a stalled review into a short one.
Questions
- Where is agent email data processed?
- Across three legs: the email provider and its sub-processors, your chosen model provider, and your own systems. The email leg is documented in the sub-processor list; the other two are yours to document.
- Does MCPmailer read or train on message content?
- No. Abuse enforcement uses sending behaviour and metadata such as volume, classification, and complaint rates, not message bodies.
- Which model provider sees the mail?
- Whichever one your agent calls. No model provider is in our sub-processor list, because the model leg is your contract, your region choice, and your retention policy.
- What is the longest-retention part of the flow?
- Usually the model provider, if it retains prompts for abuse review, or your own logs if they contain message bodies. Both are worth checking before someone asks.
- How do I reduce the amount of content leaving my systems?
- Send threads rather than raw chains, extract fields from attachments instead of passing whole documents, keep bodies out of logs, and scope each agent to the mailbox it needs.
- Can I get a DPA?
- Yes, the data processing addendum covers processing on your behalf, and the sub-processor list is the current record of who is involved.
Give your agent an address it can answer from.
Create an inbox