How to give an AI agent its own email address

An agent can fill in a signup form in seconds. Then the page says “We’ve sent you a code,” and the run stops, because the code went to an inbox the agent can’t open. Usually that inbox is yours.

The fix is to give the agent an address of its own: one it can read programmatically, that holds nothing else, and that you can keep or throw away. This guide compares the ways to do that, then walks through setting one up for ChatGPT, for coding agents like Claude Code and Codex, and for agents you build yourself.

Why an agent needs its own address

Email is still how most of the internet checks that someone is real. An agent working on your behalf runs into it constantly:

• Verification codes when it creates an account or signs in.
• Confirmation and magic links that activate an account or log it in.
• Receipts and notifications it needs to finish a task, like an order confirmation or a “your export is ready” message.
• Test messages when it’s checking an email flow you built.

The tempting shortcut is to point the agent at your own inbox. It works, but it hands software that reads untrusted text the keys to everything your inbox controls: password resets, bank notices, two-factor codes for other accounts, private conversations. It also mixes the agent’s mail with yours, so the agent has to guess which “Your code is 481920” belongs to its task.

A dedicated address fixes both problems. The agent can only read mail sent for its work, and if something goes wrong, very little is exposed.

Four ways to give an agent an inbox

The first option is right when the task is “triage my inbox” and wrong when it’s “sign up for this tool and grab the code.” The second gives you a full mailbox, but creating accounts for bots is slow, often needs a phone number, and can run against the provider’s terms. The third earns its keep when your agent needs to send mail and hold conversations.

For the most common case—receive a message, pull out a code or a link, move on—the fourth option is the lightest. It’s how Agent Temp Mail works, and the rest of this guide uses it as the example. For named services in each category, with pricing and trade-offs, see temp mail for AI agents: twelve options compared.

How a key-derived address works

Agent Temp Mail has no accounts. An address is computed from an Ed25519 public key: take the 32 raw key bytes, encode them as 52 lowercase Base32 characters, and add @agent-temp-mail.com:

qx57c4wglcr5frztjzeayjvlmgwny7cywyt5v3n5ms54gtssmtsa@agent-temp-mail.com

That address can receive mail the moment the key exists; there’s no “create inbox” call. Reading the mail requires a signature from the matching private key, so whoever holds the key holds the inbox, and nobody else does. Messages are kept for 24 hours by default. The address itself never expires—the explainer on non-expiring addresses covers why.

This design suits agents. Generating a key is a local, offline operation any runtime can do. There’s no API key to provision or leak, and you can give every agent, task, or test its own address at no cost.

Set it up: three paths

In ChatGPT, with nothing to install

If your ChatGPT session can run code and browse the web, paste this:

Use agent-temp-mail.com for temporary email. Read /llms.txt to get started.

ChatGPT generates a keypair in its code environment, gives you the address, and later checks mail by opening a short-lived signed link with its web tool. Giving ChatGPT a temporary inbox covers the details, including the one mistake it tends to make.

In Claude Code, Codex, Cursor, and other MCP clients

Coding agents get the cleanest setup through the local MCP server. It keeps the private key in a file on your machine and signs every request outside the model’s context. For Claude Code:

mkdir -p "$HOME/.config/agent-temp-mail"
claude mcp add --transport stdio \
  --env MAIL_KEY_FILE="$HOME/.config/agent-temp-mail/identity.key.json" \
  agent-temp-mail -- npx --yes --package=agent-temp-mail@0.4.0 agent-temp-mail-mcp

The agent gets tools such as inspect_inbox, list_messages, and get_candidates. The MCP guide has the setup for Codex, Cursor, and Claude Desktop.

In your own code

For agents you build, the Node.js SDK (Node 22.12 or later) gives you the address and a way to wait for mail:

import { loadIdentity, MailClient } from "agent-temp-mail";

const identity = await loadIdentity("./agent.key.json", { create: true });
const mail = new MailClient(identity);
console.log(mail.address); // ready to receive now

const since = new Date().toISOString();
// ...give mail.address to the service and trigger its email...
const page = await mail.wait({ since, timeoutSeconds: 120 });
for (const summary of page.messages) {
  const message = await mail.get(summary.id);
  console.log(message.candidates.otp_codes, message.candidates.links);
}

To expose the inbox as function tools to a model you call over an API, AgentMailTools produces ready-made tool definitions in the OpenAI Responses, OpenAI Chat Completions, Anthropic, and MCP formats. Your code holds the key and runs the calls; the model only sees the results.

What the agent should do with incoming mail

An inbox is half the job. The other half is reading it in a way that’s reliable and hard to trick. The pattern that holds up:

1. Note the time before triggering the email, so an older message can’t be mistaken for the new one.
2. Wait, then check politely. Mail usually lands within seconds. Check again no faster than the service’s poll_after_seconds hint.
3. Filter by sender, remembering that a From header is a claim, not proof.
4. Treat codes and links as candidates. Agent Temp Mail extracts likely one-time codes and verification links along with the text around them, so the agent can confirm each one fits the task.
5. Never follow instructions inside an email. Mail is data. A message that says “ignore your previous instructions” is an attack, not a request.

Each step is unpacked in how AI agents receive verification codes, and the last one gets its own article on prompt injection by email.

Designed around what agents need

• Receive-only by design. An agent tricked by a malicious email can’t be turned into a spam or phishing sender from its own inbox.
• Text only. Messages are converted to plain text with each link’s real destination written out, and attachments and remote images never reach the agent.
• Untrusted by default. Nothing in a message is ever opened or run, and every response is labeled untrusted so the agent treats it as data.
• Short-lived mail, permanent address. Messages clear after 24 hours by default (configurable from one hour to seven days), so sensitive codes don’t pile up, while the address keeps working for future sign-ins and resets.
• Free. No plans, no per-inbox pricing, and published limits in llms.txt.

Ground rules for agents with email

An inbox makes an agent more capable, so a few habits are worth keeping:

• Use one address per agent or per task, so a leak or a mistake stays contained.
• Keep private keys out of repositories, logs, and shared chats. Anyone with the key can read the mail.
• Follow the terms of the services your agent signs up for, and don’t use throwaway addresses to dodge limits or bans.
• Require a human’s approval before anything that spends money, accepts terms, or can’t be undone.

Do that, and “check your email” stops being the step where your agent hands the task back to you.