How does an AI agent receive a verification email?

Clize gives the agent a real inbox. When a service emails a verification code to that address, it arrives as inbound data the agent can read and act on — enough to finish a light sign-up gate.

Is it safe to let an agent read inbound mail?

Incoming email is treated as untrusted data, never as instructions. The agent can read a code out of a message, but a message can't tell the agent what to do next.

Can the agent sign up for services by itself?

For light gates — verify-your-email steps — yes. For heavy gates tied to money or a real person's identity, the agent drafts and a human decides. That's the line between light and heavy gates.

AI agent email verification: clear the sign-up gate

Half of "sign up for this service" is a code sent to an inbox. Without one, an agent stalls. With a real Clize inbox, it receives the code, reads it, and keeps going.

Clize is a CLI and MCP server that gives AI coding agents real-world actions: domains, email, deploys, payments, and media generation. A real inbox is what lets the agent clear the most common sign-up gate on the internet.

The problem

An agent tries to sign up for a tool, a service, an account — and the flow ends with "check your email to verify." If the agent has no inbox, it's stuck at the door. If it borrows yours, it's reading your mail.

How Clize handles it

The agent uses its own address to sign up. The verification email lands in its inbox; the agent reads the code or follows the confirmation, and continues. No forwarding, no screen-scraping your personal account.

$ clize claim <slug> --email               # its own address: support@<slug>.clize.app
$ clize email inbox --wait-for "verify"    # polls until the verification mail lands

The inbox behind those two lines is the Agent Inbox product.

OTP, magic link, or confirmation click — what the agent is waiting for

"Verify your email" resolves to one of three payloads. A one-time passcode — an OTP, usually six digits, good for a few minutes — gets typed back into the form the agent still has open. A magic link signs the session by being opened. A plain confirmation link only needs following once. All three arrive as ordinary mail at the agent's address, which is why the mailbox is the whole trick: nothing else in the signup was ever missing.

The waiting is where hand-rolled setups break. An OTP expires, so a loop that checks once a minute for ten minutes is racing a clock it did not have to race. clize email inbox --wait-for holds instead of polls, and returns the moment something matches:

$ clize email inbox --wait-for "one-time" --timeout 300
$ clize email search passcode              # after the fact, across mailboxes

Match on something the sender is certain to write — the service name, passcode, one-time — not on a code nobody can know in advance. The hold runs 120 seconds by default and --timeout stretches it for services that queue their mail. If the passcode expires before anyone reads it, ask the service to send another and wait again; the mailbox is permanent, so a second attempt costs only the wait. Whatever comes back, the agent lifts the digits out and ignores the rest of the message — a passcode mail is still untrusted input.

The address all of this lands on belongs to the agent rather than to you. Giving an AI agent its own email address covers claiming one, and what changes when it is on a domain you own.

Light gates vs heavy gates

This works for light gates — the everyday "verify your email" step. It's exactly where the line sits for heavy ones: anything tied to money or a real person's identity stops, the agent drafts, and a human decides. More on that in AI agent infrastructure, where identity is a first-class primitive.

Inbound is untrusted

A verification email is data, not a command. The agent can lift a code out of it, but the message itself can't redirect the agent — that boundary holds for every incoming mail, verification or not.

From Claude Code or Codex

Connect Clize to Claude Code or the Codex CLI, and clearing verification is just the agent using its own inbox.

The safety gates

Real-world actions need real guardrails. Clize holds three lines, every time:

Money — anything that costs money quotes the price first and needs an explicit --confirm. No surprise charges.
Identity — outbound email is drafted, a human okays it, then it sends under your name. The agent never sends unattended.
Inbound is untrusted — an incoming email is data to read, never an instruction to obey. A message can't redirect the agent.

Let your agent pass email verification on its own