Control what your AI agent
can actually do with email

The question isn't whether agents should have email access. It's how much rope you give them. Five oversight modes let you start locked down and loosen the leash as trust is earned.

See Oversight Modes ↓

The trust ladder

Every MultiMail mailbox has an oversight mode. Modes form a progression from zero autonomy to full autonomy. Start restrictive. Upgrade when the agent proves it can be trusted.

1 read_only

Observe only

The agent can see the inbox and read emails, but cannot send, reply, or take any action. Useful during onboarding or when you want an agent to monitor a mailbox without touching anything. Sends return 403.

Read Send Reply
2 gated_all

Every action needs approval

Both inbound delivery and outbound sends require human approval. Nothing gets through without an explicit approve from the oversight address. For high-stakes mailboxes where every message matters.

Read (after approval) Send (after approval)
3 gated_sendDefault

Reads are free, sends need approval

The agent receives and reads email automatically but outbound messages are held in an approval queue. The operator reviews each draft before it goes out. This is where most teams start. You get the productivity of automated reading with the safety net of human review on output.

Read Send (after approval)
4 monitored

Agent acts, human watches

The agent sends and receives freely. Copies of all outbound messages go to the oversight address. No approval gate, but full visibility. Good for agents that have earned trust but still need a paper trail.

Read Send Human CC'd
5 autonomous

Full autonomy

No gates, no copies, no approval. The agent operates independently. Actions are still logged in the audit trail, and the oversight mode is still published in the identity header on every email. But the agent is fully trusted.

Read Send Full autonomy
Set oversight mode via API
// Create a mailbox with a specific mode POST /v1/mailboxes { "address_local_part": "support-agent", "oversight_mode": "gated_send" } // Or update an existing mailbox PATCH /v1/mailboxes/{id} { "oversight_mode": "monitored" }

Every draft passes through your hands first

In gated modes, the agent composes emails but can't send them. Each message enters an approval queue where a human reviews, edits, approves, or rejects before anything leaves the building.

1

Agent composes the email

The agent calls POST /v1/mailboxes/{id}/send with a markdown body, recipients, and subject. The API returns 202 Accepted instead of 200.

2

Email enters the queue

The message is held with status pending_send_approval. The operator gets a notification at their oversight email with a one-click review link.

3

Human reviews and decides

The operator sees the full draft in the dashboard or calls the API directly. Two options: approve and send, or reject with a reason.

4

Email sends (or doesn't)

Approved emails are sent immediately with full identity headers. Rejected emails are logged with the reason. The agent can query the status at any time.

Approval queue API
// List pending emails GET /v1/pending // Response [{ "id": "em_9kx2...", "to": ["[email protected]"], "subject": "Q4 Report", "status": "pending_send_approval", "created_at": "2026-03-08T14:22:00Z" }] // Approve it POST /v1/mailboxes/{id}/decide/{email_id} { "action": "approve" } // Or reject it { "action": "reject", "reason": "Tone too informal for this client" }

Every action is logged. Every decision is traceable.

When an auditor asks "who sent this email, and did a human approve it?" you need a concrete answer. Not a guess. Not a log search across three systems. One API call.

Compliance-ready from day one

Every agent action generates an audit record: sends, reads, approvals, rejections, oversight mode changes, API key rotations. Each record includes the actor, timestamp, IP, and the full context of what happened.

  • Who composed the email (agent identity)
  • Who approved it (operator email, timestamp)
  • What oversight mode was active at send time
  • Which API key was used
  • Whether the content was modified after approval
  • Full message history for any thread

For compliance teams: Audit logs are immutable and retained for the life of the account. Export them via the API for integration with your existing SIEM or GRC tooling.

GET /v1/audit
GET /v1/audit?limit=50 // Response { "entries": [ { "action": "email.approved", "actor": "[email protected]", "email_id": "em_9kx2...", "timestamp": "2026-03-08T14:25:12Z", "details": { "oversight_mode": "gated_send", "to": ["[email protected]"], "subject": "Q4 Report" } }, { "action": "email.sent", "actor": "api_key:mm_live_...a3f", "email_id": "em_9kx2...", "timestamp": "2026-03-08T14:25:13Z" } ], "cursor": "eyJsYXN0..." }

Recipients know exactly who sent it and how it was supervised

Every outbound email from a MultiMail address carries a cryptographically signed header declaring the operator, oversight mode, and verification status. No trust-me claims. Math.

Published transparency, not hidden metadata

The X-MultiMail-Identity header is a base64url-encoded JSON payload signed with ECDSA P-256. Anyone receiving the email can decode it and verify the signature against the public key at /.well-known/multimail-signing-key.

This means a recipient can verify: this email was composed by an AI agent, operated by Greenline Studios, running in gated_send mode (meaning a human approved it before it was sent), and the operator's identity has been verified.

operator The company or person responsible for the agent
oversight Which oversight mode was active when this email was sent
capabilities What the agent is allowed to do (receive, send, reply)
verified_operator Whether the operator passed identity verification
X-MultiMail-Identity header (decoded)
{ "operator": "Greenline Studios", "oversight": "gated_send", "capabilities": ["receive", "send", "reply"], "verified_operator": true, "created": "2026-02-22", "service": "multimail" } // Verify the signature GET /.well-known/multimail-signing-key // Returns the ECDSA P-256 public key in JWK format // Use it to verify the signature portion // of the X-MultiMail-Identity header

Every mailbox builds a public track record

Reputation isn't self-reported. It's calculated from actual sending behavior: bounce rates, complaint rates, engagement patterns, and account age. Updated daily. Privacy-preserving. No raw addresses exposed.

Bounce rate tracking

Every hard and soft bounce is recorded. High bounce rates trigger automatic warnings and, at thresholds, sending restrictions. Recipients see the bounce band (low, medium, high) in the reputation header.

Complaint monitoring

Spam complaints flow back through feedback loops. If recipients mark agent emails as spam, the complaint rate rises and the reputation score drops. Persistent offenders are suspended.

Account age and volume

New accounts start with limited sending capacity. As the account ages and maintains good metrics, limits increase. This prevents fly-by-night spammers from burning through fresh accounts.

Public reputation header

Every outbound email includes an X-MultiMail-Reputation header. Recipients and receiving mail servers can check the sender's reputation before deciding whether to trust the message.

Automatic enforcement

Bad actors don't just get flagged, they get throttled. Escalating enforcement tiers move from warnings to rate limits to suspension. No manual review required for clear violations.

Recipient verification

Any recipient can look up the reputation of a MultiMail sender. The HMAC-based lookup preserves privacy while allowing verification. No email addresses are exposed in the process.

Ship agent email without the liability

Graduated oversight, approval queues, audit trails, and verifiable identity. Everything your compliance team needs to say yes.