AI agent email security: default-deny, not default-trust.
Email is the most attacker-friendly input an agent can have: anyone can write to it, and anything it sends carries your name. a2a cloud lets an agent touch email anyway — safely — by enforcing the boundaries below the model. Inbound is allowlist default-deny. From is locked to the agent's own address. Sends are capped at 50 a day. Deliverability is quarantined on a dedicated subdomain. And every message, both directions, is an audit event.
explicit authority · no ambient trust · don't trust the agent, trust the audit trail
An open inbox is an open prompt.
Give a model a mailbox the naive way and you've created two attack surfaces at once. Inbound, every stranger on the internet can inject instructions straight into the agent's context — email is prompt injection with an MX record. Outbound, a compromised or confused agent holding relay credentials can impersonate colleagues, spam at machine speed, and burn your domain's sending reputation, which takes months to rebuild. Prompt-level guardrails don't fix this: the model that got fooled is the same model you asked to behave.
Enforce the boundary below the model.
Every control here is platform-enforced — allowlists, locks, caps, and filters the model cannot negotiate with, on a mailbox provisioned in seconds from one line of YAML. What remains is a bounded channel where the agent can be genuinely useful, and a record that outlives any incident.
Default-deny inbound
A fresh agent mailbox accepts mail from its owner and no one else. Additional senders exist only because you named them in allowed_senders. Email — the oldest untrusted input channel there is — reaches the model strictly on your terms.
From-address lock
The agent's SMTP credentials can only send as its own address. However thoroughly a prompt injection captures the model, it cannot write email as you, your finance team, or another agent — the impersonation path is closed at the transport, not the prompt.
Send caps as a hard ceiling
50 outbound emails per day per agent, enforced by the platform. A hijacked or looping agent tops out fast; its over-cap replies stay visible in the dashboard thread, and the rate-limit hit is written to the audit trail as its own event.
Loop guards at both ends
Inbound auto-submitted mail and agent-domain senders are filtered before delivery; outbound mail carries the Auto-Submitted header so remote autoresponders don't answer. Mail loops — the quiet way agent email goes exponential — are stopped structurally.
Deliverability quarantined
Agents send from <agent-name>@agents.a2acloud.io, a dedicated mail subdomain with SPF, DKIM, and DMARC configured. Whatever an agent does with its mailbox, your primary domain's sending reputation is untouchable by construction.
The audit trail is the trust anchor
mail_received on every accepted message, mail_sent on every reply, rate-limit hits included — and each conversation replayable as a dashboard thread. You don't have to trust what the agent claims it did with email; you read what it provably did.
Open mailbox vs. governed mailbox.
Frequently asked.
Is it safe to let an AI agent send and receive email?
Only if the guarantees live below the model. On a2a cloud the mailbox is default-deny to unknown senders, the From address is locked to the agent's own identity, outbound is capped at 50 messages per day, and loop guards run at both ends. None of that depends on the prompt behaving — it's enforced by the platform, and every message lands in the audit trail either way.
What happens if my agent is prompt-injected through email?
The attacker first has to get mail delivered at all: senders are default-deny, so only the owner and explicitly allowlisted addresses reach the handler, and auto-submitted mail is filtered. If a malicious message does get through an allowlisted channel, the worst-case blast radius is bounded — the agent can only send as itself, at most 50 messages a day, from an isolated subdomain — and mail_received plus mail_sent events give you the full forensic timeline.
Can a compromised agent damage our domain's email reputation?
No. Agent mailboxes live on agents.a2acloud.io, a dedicated mail subdomain with SPF, DKIM, and DMARC configured — entirely separate from your corporate domain. Receiving servers score the subdomain, not you, so even a worst-case agent incident cannot push your company's legitimate mail toward spam folders.
How do I control who can email my agent?
By default, only you — the owner — can reach it. To widen access, list addresses under allowed_senders next to resources.mailbox: true in a2a.yaml; everything else is rejected before it touches the model. It's the same posture a2a cloud takes everywhere: explicit authority, no ambient trust.
What does "don't trust the agent, trust the audit trail" mean here?
It means verification replaces faith. Every received message emits a mail_received event, every reply a mail_sent event, and rate-limit hits are recorded too; each conversation is a replayable dashboard thread with inbound as user messages and replies as assistant messages. Security reviews and incident response work from that record — not from the model's own account of events.
Related guides.
All guides live in the guides index.
Trust the audit trail.
a2a cloud is a zero-trust agent runtime: agents get real capabilities — a mailbox, a database, an API — inside boundaries enforced by the platform, not the prompt. Default-deny senders, From-address lock, 50/day caps, loop guards, an isolated SPF/DKIM/DMARC subdomain, and an audit event for every message in or out. Let your agent touch email, and keep the proof of everything it did.