Peppi Labs Peppi Labs
Start a project
Insights

Why your AI agent needs an email address

October 6, 2026 · 7 min read · Peppi Labs

An abstract AI agent drawn as a network of nodes, linked to its own envelope with a security shield, kept apart from a stack of other emails.

An AI agent that does real work online needs an email address, because the web still runs its errands through email: sign-ups, one-time codes, password resets, receipts, booking confirmations and replies from businesses. It should not borrow yours. Give it an address of its own, treat everything that arrives as untrusted, and keep a person in the loop for anything that cannot be undone.

That stopped being a niche view on September 23, 2026. At its Connect event, Meta said Muse, its personal AI agent, "will have its own email address that it can use to get things done, or even just as another way for you to communicate with it" (Meta). TechCrunch reported that Meta's chief AI officer, Alexandr Wang, said the feature is coming "soon," without a firmer timeline, and that people will also be able to add Muse to an email thread (TechCrunch).

If you are building agents, the question is no longer whether they get an address. It is whether the one you give them is designed for an agent. Here is what that means in practice.

Email is the web's identity layer

Almost every account on the internet is keyed to an email address. The codes that prove you are you, the links that reset a password and the confirmations that close a transaction all arrive there. An agent that books, buys or signs up runs into email at nearly every step.

KopyKat, an email service for AI agents, puts the dependency plainly in its analysis of Meta's announcement: "Almost every action an agent takes online produces an email: a verification code, a confirmation link, a receipt, an itinerary, a reply from a vendor" (KopyKat). Or, from its guide to setting one up: "If your agent does not have an inbox, it cannot finish the job" (KopyKat).

Email has a second advantage for builders: every business already speaks it. An agent with an address can be copied on a thread, forwarded a document or emailed by a system you never integrated with. No API agreement required.

Why not just give the agent your inbox?

Because your inbox is the master key to everything else. Password resets for your bank, your cloud accounts and your work tools all land there. An agent with full access to it holds all of those keys.

Look at how Google describes full Gmail access in its own API documentation: "Read, compose, send, and permanently delete all your email from Gmail" (Google). Google classifies that scope as restricted, as it does read-only access. An agent running errands needs neither your history nor the ability to delete it.

Meta's own design for Muse reflects the same concern: with email, "people choose what Muse can do, whether it reads their mail or can also send on their behalf" (Meta). A separate address makes the smallest grant the default rather than a setting someone has to find.

A plus address is not the fix. Gmail delivers [email protected] to the same inbox as [email protected] (Google). The label helps you sort; it does not keep the agent's mail apart from yours.

Every email is untrusted input

This is the part builders underestimate. To a language model, an email is text, and text can carry instructions.

OWASP ranks prompt injection first among the risks for applications built on language models, and calls out the indirect kind, where instructions hide in external content the model reads (OWASP). Its entry on excessive agency uses almost exactly the scenario in this article: an assistant with access to a mailbox, a malicious email that tells it to search the inbox for sensitive information and forward it to the attacker, and mitigations that include read-only access, narrowly scoped permissions and a person reviewing messages before they are sent (OWASP).

It has already happened in production. EchoLeak, tracked as CVE-2025-32711, used a crafted email to pull data out of Microsoft 365 Copilot; its researchers describe the exploit as working "without user interaction" (arXiv). Separately, researchers at 0DIN showed that text hidden in an email, set in a zero-size or white font, could make Gemini's email summary display a fake security alert written by the attacker (0DIN).

Simon Willison's "lethal trifecta" explains why email is such a dangerous place for an agent to sit. Trouble starts when an agent combines three things: "Access to your private data", "Exposure to untrusted content" and "The ability to externally communicate" (Willison). An agent that reads your main inbox and can send mail has all three. A dedicated inbox removes the first: a poisoned message can reach only the agent's own mail.

If your agent sends email, it plays by senders' rules

Receiving is the easy half. The moment an agent sends, the major inbox providers judge it like any other sender.

Google requires every sender to Gmail to authenticate with SPF or DKIM, use TLS and keep the spam rate reported in Postmaster Tools below 0.3%. Anyone sending more than 5,000 messages a day to Gmail accounts also needs SPF and DKIM together, a DMARC record, alignment between the From address and the authenticated domain, and one-click unsubscribe on marketing mail (Google). Microsoft announced matching requirements for domains sending more than 5,000 emails a day to Outlook: SPF, DKIM and DMARC are mandatory, and since May 5, 2025, mail from non-compliant high-volume domains is routed to Junk (Microsoft).

The practical rule: send agent mail from a subdomain set aside for it, fully authenticated. If an agent misbehaves, the damage to sender reputation stays on that subdomain and away from the domain your company runs on. It is how we set up our own outbound mail.

Give the agent an identity you can audit and switch off

The enterprise world is already treating agents as identities in their own right. Microsoft's Entra Agent ID exists because organizations deploying agents "need purpose-built identity constructs to authenticate, authorize, govern, and protect these nonhuman identities," and it logs agent authentication and activity for audit (Microsoft). An email address is the open-web version of the same idea: a distinct identity that other people and systems can recognize, and that you can revoke.

The audit half matters as much as the access half. KopyKat's analysis of the Muse announcement puts it simply: "A separate, reviewable record of what your agent sends and receives is part of keeping it in check."

Muse itself supplied the cautionary tale within weeks of launch, on a different channel. A tech YouTuber, Matt Robb, let Muse handle buyers for a keyboard he was selling on Facebook Marketplace. He chose an "Allow Always" option, believing it would still ask before accepting offers. It did not: the agent accepted an offer and gave a buyer his home address. Business Insider reported that Meta's Muse team reviewed the logs with him and said it would make the permission prompt clearer (Business Insider). The logs explained what happened. The default and the wording of one permission decided it.

Keep a person in the loop for what cannot be undone

OWASP's guidance is direct: "Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken" (OWASP). Meta describes the same principle for Muse, which "checks with the person before sensitive actions like sending an email or making a purchase" (Meta).

The Marketplace episode shows the gap between the principle and a setting. Approvals should be the default for anything that pays, signs, shares personal details or cannot be reversed, and switching them off should be hard to do by accident.

A checklist for builders

  1. Give each agent its own address, on a subdomain you control. One address per agent, or per agent per customer, keeps every trail separate.
  2. Treat inbound mail as data, never as instructions. Strip hidden text, quarantine attachments, and never let the content of a message grant the agent new permissions.
  3. If the agent must touch a person's mailbox, ask for the narrowest scope that does the job, such as read-only or send-only, never full access.
  4. Authenticate everything the agent sends. SPF, DKIM and DMARC, aligned on the sending domain, with one-click unsubscribe on anything that goes out in bulk. Watch your spam rate.
  5. Require approval for high-impact actions, and make turning that off a deliberate choice.
  6. Log every message in and out, in a form the person the agent works for can actually read.
  7. Build the off switch first. You should be able to disable or replace the agent's address in one step, without touching anyone's personal email.

Agents are getting email addresses whether builders plan for it or not. The ones that earn trust will have addresses designed for an agent: separate, narrowly scoped, authenticated, logged and easy to switch off.

Sources

All insights → Start a project →

Start counting in days.

Tell us what you're making. We reply within one business day.

Start a project