How to give an AI agent its own email address

Create a mailbox just for the agent on a domain you control, such as billing@yourcompany.com, and give the agent a credential that reaches that mailbox and nothing else. Before it sends anything, decide who it may write to without asking a person, what mail it may read, and how its emails say an AI wrote them. Forwarding your own mail to an agent, or giving it your password, hands it far more than it needs.

Why should an agent have an address of its own?

• Your inbox stays out of reach. A person’s mailbox holds years of private mail, contracts and password resets. An agent working in it sees all of that, and so does anyone who manages to trick it.
• People know who they’re dealing with. billing@ is a role; ana@ is a person. An agent writing as Ana is pretending to be her.
• You can switch it off on its own. Revoke its key or pause it without touching anyone’s account.
• Its record is its own. Everything it read and sent sits in one mailbox, so a mistake can be traced.

What are your options?

What each one costs at list prices is in what an email inbox for an AI agent costs.

How do you set it up?

Whichever option you pick, the same seven decisions keep an agent useful and contained:

1. Pick an address that says what it does. A role on your own domain (billing@, support@, bookings@) tells people what to expect and keeps replies with your business.
2. Name a person who answers for it. Someone has to approve its emails, read its alerts and switch it off. Write their name down before the agent sends anything.
3. Give it a key to that one mailbox. An API key or sign-in limited to the agent’s own mailbox, with an expiry if you can set one. Never a person’s password, and never a credential that works on every mailbox in the company.
4. Decide what it may send without asking. A good default: replies to people it already writes with go out; the first email to anyone new waits for a person (human-in-the-loop email); and a daily limit catches runaway loops.
5. Decide what it may read. Mail from senders who fail authentication shouldn’t reach it, and text a person can’t see shouldn’t either (prompt injection by email).
6. Make it say it’s an AI. A line at the end of each email naming the agent and who it works for (what the EU AI Act asks).
7. Watch it, and keep a pause button. Spam complaints and bounces on its mail should stop it before they hurt the domain your team sends from (should an agent send from your own domain?).

How does the agent read and send?

Through an API, ideally. The agent lists and reads messages and sends replies with HTTP calls, and a webhook tells your code when something arrives. Assistants that speak MCP, such as Claude Code, Codex and Cursor, can use the same mailbox as a set of tools.

IMAP and SMTP work too, but they were built for mail apps used by people: a password that opens IMAP shows every message, and one that opens SMTP sends anything to anyone. Rules about recipients, approvals and limits only hold if the mail system applies them, and a plain mail-app connection skips them.

Which mistakes give an agent too much?

• Sharing a person’s login. The agent can then do anything that person can, everywhere that password works.
• Forwarding a person’s mail to it. Every email anyone sends them becomes something the agent reads and could act on.
• Company-wide credentials. A key that reaches every mailbox turns one tricked agent into a leak of everyone’s mail.
• No owner. An agent nobody answers for keeps sending long after anyone checks what it says.

How do you do it on SuperMailOS?

An agent inbox is a mailbox on one of your verified domains, next to your team’s, with a person who answers for it. Its key reaches that inbox and nothing else. New recipients wait for a person by default, mail that fails sender checks is held back from it, and every email it sends ends with a line like “Sent by Billing assistant, an AI agent working for Ana Ruiz at Acme.” Agent inboxes come with your seats, 2 per seat on Pro and 5 on Business. Creating one is a single API call that returns the agent’s key:

curl -X POST "https://supermailos.com/api/v1/inboxes" \
  -H "Authorization: Bearer $SUPERMAILOS_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"name": "Billing assistant", "createKey": true}'

Then the agent connects with that key, here as an MCP server in Claude Code:

claude mcp add --transport http \
  billing-assistant https://supermailos.com/mcp \
  --header "Authorization: Bearer $AGENT_KEY"

Or create it in Settings → Agents. The agent inboxes guide has every setting, and AI agent inboxes the overview.

Sources

• Google Cloud, Best practices for using service accounts securely, and Google Workspace, Control API access with domain-wide delegation.
• Microsoft, About shared mailboxes, Microsoft Graph permissions reference (Mail.Send) and Role Based Access Control for Applications in Exchange Online.
• Regulation (EU) 2024/1689 (the AI Act), Article 50.

Questions