Email as identity for AI agents

On much of the internet, you are your email address. Password resets, vendor invites, package registries, and banking OTPs all assume a mailbox that only the rightful party controls. AI agents that must complete those flows need identity—not a temporary chat session and not a human’s personal login borrowed through OAuth.

Domain is organizational identity

SPF, DKIM, and DMARC bind sending to a domain the organization controls. Recipients and filters decide trust from that cryptography and from reputation history. An agent that sends as role@yourdomain participates in the organization’s identity. An agent that sends through a random personal Gmail participates in a person’s identity—and breaks when that person leaves.

Authenticate domains properly. Split subdomains when traffic types differ: transactional billing should not share fate with cold outreach. Warm new streams. Treat complaints as security and deliverability incidents alike. Practical rules: deliverability 101.

OTP and signup are identity protocols

When a coding agent needs a registry token, the OTP arrives by email. When a vendor onboards a service account, the invite arrives by email. If the agent lacks a mailbox, a human becomes a paste buffer—and the audit trail lies. Agent Inbox gives the role an address vendors can reach; Neuro OS keeps the send and any sensitive follow-up behind Ask.

Why OAuth-to-Gmail is the wrong identity

OAuth into a person’s mailbox looks convenient in a demo. It couples agent work to human credentials, blurs consent, and creates exfiltration paths the person never intended. It also fails multi-agent scale: ten roles should not share one founder’s inbox. Provisioned inboxes reverse the model—see can AI agents have their own email.

Accountability still needs a human owner

Identity for the agent is the address and the scoped keys. Accountability for the company is the role owner and the Ask gate. Pattern Automation does not treat a mailbox as a license for unattended root. Writes and sends default to Ask. Self-host when 152-FZ or customer policy requires data residency.

Forwarding and proof

Forwarding preserves headers and context when work moves between human and agent. That matters for disputes and for internal review: you can show what arrived, what was proposed, and who approved the outbound reply. Threading standards keep the identity of the conversation intact—email threading.

Agents are becoming users of networked systems. Users need addresses that authenticate, receive secrets, and leave an audit trail. Email already does that. Give roles mailboxes; keep people on the gates; stop pretending a personal OAuth token is an agent identity.

For the broader autonomy argument, read autonomous coding agents and the next trillion users.

Practical identity controls

Bind each production role to one primary address. Record the owner, the approving managers for Ask, and the systems allowed to forward into that inbox. Reject OAuth demos that grant a model broad read on a human mailbox “just for testing” on real customer data. Testing belongs on disposable inboxes with synthetic mail.

When an agent must prove it sent a message, preserve Message-IDs and approval records together. Identity without audit is only a From header. Identity with Ask and logs is an operating control.

Interop with existing stacks

Many enterprises already route exceptions from 1C, Bitrix, or amoCRM through mail. That does not mean the agent should inherit a shared departmental alias. Create role inboxes and forward selected streams. The agent identity stays crisp; the legacy systems keep their notification habits until native connectors exist.

Agent Inbox gives each role a mailbox people can reply to, with forwarding into Neuro OS when a human must see the thread. Outbound mail defaults to Ask. Run the role on Neuro OS. To scope the first inbox, get started.

Explore Neuro OS →