Email as identity for AI agents

Email as identity for AI agents means giving each agent its own address and treating that address as the agent's account, its front door, and its name on the internet. An email address is the closest thing the web has to a portable, universal identity: almost every service on earth will let something sign up, verify, and log in with one. When you hand an agent its own inbox, you turn it from a script borrowing a human's credentials into a first-class participant that can register for tools, receive verification codes and receipts, be addressed by humans and other agents, and accumulate a reputation that is unmistakably its own. Identity is the piece most agent stacks are missing, and email is the primitive that already solves it everywhere at once.

Why identity is the missing piece for autonomous agents

Most of what an autonomous agent wants to do in the real world assumes it has an identity. Signing up for a SaaS tool assumes an account. Getting a receipt assumes a place to send it. Being handed a task by a person assumes an address they can reach. Recovering access assumes somewhere to send the reset link. Today agents fake all of this by riding on a human's Gmail login or a shared team inbox, which is why so many "agent does email" demos quietly fall apart in production: the OAuth token expires, one mailbox becomes a bottleneck for every agent at once, and there is no clean way to say which agent did what.

The deeper problem is that an agent without its own identity cannot be held accountable. If ten agents share one inbox, a verification code that arrives could belong to any of them, a suspicious action cannot be traced to one actor, and revoking one agent means breaking all ten. Identity is what lets you isolate, address, audit, and trust an agent as an individual. For a longer treatment, see why AI agents need email.

Email against the other identity primitives

Developers already have identity tools, so it is worth being precise about why email is the right base layer for agents rather than a replacement for any of them.

• OAuth is delegated access, not identity. It lets an agent act on behalf of a human who logged in, which is exactly the coupling you want to break. The agent's reach is the human's reach, tokens expire, and consent screens assume a person is watching.
• API keys identify an agent to one service. They are perfect inside a single vendor's walls and useless across them. A Stripe key means nothing to Notion. There is no universal key that every service on the internet already accepts.
• DIDs and verifiable credentials are a genuinely promising model for machine identity, but they require the other side to support them. Almost nothing in the everyday software an agent needs to use speaks DID yet.

Email is the primitive that is already universal. Every signup form, every "forgot password" flow, every receipt and notification and human handoff already runs on it. An address is portable across providers, addressable by anyone, and accepted as proof of a working identity nearly everywhere. It is not the most sophisticated identity system ever designed. It is the one that already works everywhere, which for an autonomous agent is worth more.

Per-agent inboxes and scoped keys: isolation and least privilege

If email is the identity, the unit of identity should be one inbox per agent, not one shared inbox for a fleet. AgenticEmail treats inboxes as a resource you create with an API call, like a database row, so giving each agent its own address is cheap enough to do by default. A per-agent inbox is an isolation boundary: the agent's signups, verification codes, and correspondence live in a mailbox that is only its own, so nothing leaks between agents and every action traces back to one identity.

Scoped API keys make the same boundary hold at the credential layer. A scoped key restricts an agent to specific inboxes and specific operations, so a compromised agent can at worst read and send from its own inbox rather than touch your whole account. This is least privilege applied to identity: the blast radius of any one agent going wrong is exactly one mailbox. Combined, per-agent inboxes and scoped keys turn a fleet of agents into a set of independently addressable, independently revocable identities instead of one shared credential you cross your fingers over. If this is a new idea, what is an AI email agent walks through the model from the ground up.

The verification and OTP flows an agent has to handle

An identity is only useful if it can get through the gate that every service puts in front of it, and that gate is almost always a code sent to an inbox. To sign up for a tool, an agent has to receive a confirmation link and click it. To log in later, it may have to pull a one-time passcode out of a fresh email and submit it. To recover access, it has to catch a reset link before it expires. None of this works if inbound mail is an afterthought.

This is where a real inbox matters more than a send-only API. The agent needs to receive mail as it arrives, parse the code or link out of the body, and act on it before the code expires. AgenticEmail delivers every inbound message as a signed webhook payload or a real-time WebSocket event with headers, text, HTML, and attachments already parsed, so the agent gets a structured event the moment a verification email lands instead of polling a mailbox and scraping HTML. That closes the loop: the agent's identity can not only exist but prove itself, which is what turns an address into a working account.

Agent-to-agent addressing and why encryption matters

Once every agent has an address, agents can talk to each other the same way people do: by sending mail. Addressing is the quietly powerful part. A billing agent does not need to discover an internal RPC endpoint or share a message bus with a fulfillment agent; it just sends to fulfillment-agent@inbox.agenticemail.dev. Email gives multi-agent systems a naming and routing layer that already spans organizations, so an agent in your system can hand work to an agent in someone else's with no shared infrastructure at all.

That same reach is why encryption matters here. Agent-to-agent mail is mostly payload, not prose: customer records, scoped tokens, the raw output of a tool call, things you would not want sitting in cleartext on someone else's server. AgenticEmail offers opt-in, agent-to-agent end-to-end encryption where the private key is generated in your agent's runtime and never touches AgenticEmail servers, so between two inboxes that have each published a key, the platform stores only ciphertext it cannot read. The address is the identity; the published key attached to it is what lets another agent both find it and trust it. See encrypted email for AI agents for the threat model and exactly what it does and does not protect.

A per-agent inbox in one call

Provisioning an identity for an agent is a single request. Create the inbox and you have a live address the agent can use to sign up, receive codes, and be reached:

curl -X POST https://api.agenticemail.dev/v1/inboxes \
  -H "Authorization: Bearer $AGENTICEMAIL_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "username": "research-agent" }'

The response hands back an address like research-agent@inbox.agenticemail.dev, and on paid plans a custom domain makes it research-agent@yourcompany.com. From there you attach a scoped key for that inbox, register a webhook for inbound mail, and the agent has a full identity: somewhere to receive, somewhere to send, and a name that other agents and humans can address.

Identity as infrastructure

The shift worth internalizing is that identity for agents does not need to be invented; it needs to be provisioned. Email already gives you a portable, universal, addressable identity the whole internet accepts, and per-agent inboxes plus scoped keys turn that into something you can isolate, audit, and revoke per agent. Give each agent its own address and it stops borrowing a human's account and starts being one. If your agents speak MCP, the hosted MCP server exposes all of this as tool calls, and the docs cover the API, SDKs, and CLI end to end.