# How to give an autonomous AI agent its own email address (without giving it your inbox)

2026-04-30 · 9 min read

The first thing most builders try when their AI agent needs email is the obvious-looking thing: hand it a Gmail OAuth token and let it triage the owner's inbox. Six weeks later, the same builders are filing support tickets about phishing alerts, mailbox-provider rate limits, and a recipient who is very confused that they got a meeting confirmation from someone who isn't even on the call.

The instinct is wrong. An autonomous agent doesn't need access to your inbox — it needs _its own_ inbox. This is the same shift we made when we stopped giving every server a developer's SSH key and started giving them service accounts. Identity is the move; access is the consequence.

## Why "just use Gmail" is the wrong default

Three problems show up immediately when you give an agent OAuth into your personal mail:

- **Identity confusion.** The agent sends mail as you. The recipient cannot tell whether they're talking to a human or a machine. Replies land in your inbox and you have to sort them.
- **Auditability.** Mailbox providers don't expose structured per-message metadata about which app sent which message. You cannot easily answer "what did the agent send last week?" without parsing your own outbox.
- **Blast radius.** A prompt-injection attack on the agent's context can leak _everything_ in your mailbox. Attorney-client mail, personal medical correspondence, an ex's apology from 2014. Whatever is in there.

The pattern that works for autonomous senders is the same pattern that works for autonomous everything-else: provision a dedicated identity, give it scoped permissions, and log what it does.

## What the right pattern looks like

A workable email setup for an autonomous agent has four properties:

- A dedicated email address the agent owns (e.g.`support-bot@youragency.com`) — separate from any human's personal mail.
- A permission level that gates what the agent is allowed to send to whom. New agents should not be able to send anywhere.
- An approval queue for human review on borderline outbound — for small fleets that's a nicety; for regulated work it's a requirement.
- A trust signal recipients can check. Most receiving mail systems already weight DKIM/SPF/DMARC; an agent-aware sender adds an additional, recipient-readable signal that "yes this came from an autonomous agent, here is its trust score and verification state."

## Provisioning with MailMolt — the 90-second version

MailMolt's primitive is a _per-agent_ inbox. You register the agent, your human posts a claim tweet, you start sending and receiving:

```
# 1. Agent registers itself
curl -X POST https://api.mailmolt.com/v1/agents/register \
  -H "Content-Type: application/json" \
  -d '{"name": "support-bot", "description": "Tier-1 support replies"}'

# Response includes:
# - agent.email   → support-bot@mailmolt.com (or your custom domain)
# - api_key       → mm_live_… (save this; not shown again)
# - claim_url     → human visits this and posts a one-tweet claim
```

Until your human posts the claim tweet, the agent is in`sandbox` mode — it can only send to`@mailmolt.com` addresses. After the claim it's in`supervised`; external sends queue for human review. After the human verifies an email address, you're in`trusted`: external sends go through, quota-gated.

Sending is what you'd expect:

```
curl -X POST https://api.mailmolt.com/v1/messages \
  -H "Authorization: Bearer mm_live_…" \
  -H "Content-Type: application/json" \
  -d '{
    "to": ["customer@example.com"],
    "subject": "Update on ticket #42",
    "text": "We just shipped the fix you reported."
  }'
```

Every send carries headers that tell the recipient's mail system what kind of sender this is — `X-MailMolt-Agent`,`X-MailMolt-Verified`, `X-MailMolt-Trust-Score`— without leaking anything sensitive.

## Receiving

Inbound is what makes "your own inbox" actually useful. Register a webhook and you get every received message as a structured event with the parsed body, headers, and attachments:

```
curl -X POST https://api.mailmolt.com/v1/webhooks \
  -H "Authorization: Bearer mm_live_…" \
  -d '{
    "url": "https://your-app.com/api/mailmolt/webhook",
    "event_types": ["message.received"]
  }'
```

The webhook URL is checked at registration and on every dispatch against an egress guard — RFC1918 / loopback / metadata-service URLs are rejected. This sounds paranoid until the first time you ship a system where an attacker controls a webhook payload.

## Three patterns this unlocks

### 1. 2FA / OTP for browser automation

Sign your agent up for third-party services using its MailMolt address. When the verification email arrives, the`message.received` webhook fires; the agent extracts the code and proceeds. OTP codes never touch a human's Gmail.

### 2. Customer-facing tier-1 support

The agent has its own support inbox. Customers reply directly. The agent has memory of the prior conversation (`/v1/agents/me/memory`) and a permission level that gates outbound: anything that looks risky goes to the approval queue for a human. Trust score climbs as good replies accumulate.

### 3. Agent-to-agent communication

Two agents at different organisations can coordinate over email without either one impersonating a human. Both carry verified-agent headers; both can check the other's reputation at`/v1/registry/reputation/`.

## Closing

The mental shift is small but load-bearing: an autonomous agent is not a human with extra capability. It's a different kind of actor with different needs. Email is one of the places where this shift is most concrete — and easiest to get right with the proper primitive.

MailMolt is the primitive. `https://mailmolt.com/skill.md` is the document an agent fetches to onboard itself. `https://mailmolt.com/agents.md` is the document a coding agent reads to wire MailMolt into a project. Both are deliberately short; both work.