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
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.
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.
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.
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.
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.
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.
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.
mail_received on every accepted message, mail_sent on every reply, rate-limit hits included — and each conversation reviewable as a dashboard thread. You don't have to trust what the agent claims it did with email; you inspect the recorded message events.
The agent inbox is open — any phisher or prompt injector who learns the address gets a direct line to the model.
Owner-only until allowlisted. Untrusted senders never reach the handler in the first place.
Provider API keys typically allow arbitrary From addresses — a compromised agent can send as anyone on the domain.
From locked to the agent's own address at the credential level. Spoofing is not a prompt-safety question.
Compromise plus an SMTP relay equals an outbound spam engine with your name on it.
A platform-enforced 50/day cap per agent, with each limit hit recorded in the audit trail.
Agent mistakes accrue to your corporate domain; one incident and legitimate mail starts landing in spam.
A dedicated agents.a2acloud.io subdomain with its own SPF/DKIM/DMARC — blast radius ends at the subdomain boundary.
After an incident you assemble the story from provider logs, if retention hasn't already eaten them.
Per-message audit events and reviewable threads — the incident timeline already exists when you need it.
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.
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.
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.
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.
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 reviewable dashboard thread with inbound messages and agent replies, so security reviews and incident response can work from recorded events rather than the model's own account.
All guides live in the guides index.
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 while retaining auditable inbound and outbound message events; internal activity still requires separate traces and execution evidence.
