Email as Identity for AI Agents

Why email is the identity layer

Think about how you prove your identity online. You enter an email address. The service sends a code. You type the code. Identity confirmed. This pattern is so universal that it has become invisible — but it underpins almost every authenticated interaction on the web.

For AI agents, this creates a hard dependency. An agent that cannot read email cannot:

• Sign up for new services or APIs
• Complete two-factor authentication flows
• Recover accounts when tokens expire
• Verify domain ownership
• Receive and act on webhook notifications sent via email

The inbox is not just a communication channel — it is a credential store.

Extract OTP codes from verification emails

The most common identity flow is OTP (one-time password) verification. A service sends a 4-8 digit code to your email, and you have a few minutes to enter it. Nylas CLI has a dedicated otp command that handles this in one step:

# Get the latest OTP code (auto-copies to clipboard)
nylas otp get

# Get OTP for a specific email account
nylas otp get agent@company.com

# Output just the raw code (for piping to scripts)
nylas otp get --raw

# Use in a script: capture the code and submit it
CODE=$(nylas otp get --raw)
echo "Verification code: $CODE"

The otp get command scans recent messages, identifies OTP patterns (4-8 digit codes from verification senders), and extracts the code — no jq, no regex, no manual parsing. It also copies the code to your clipboard automatically.

Watch for incoming verification codes

Verification emails do not arrive instantly. An agent needs to wait for the code to land. The otp watch command handles this natively:

# Watch for new OTP codes in real-time (default: checks every 10 seconds)
nylas otp watch

# Watch with a faster check interval (every 3 seconds)
nylas otp watch --interval 3

# Watch a specific account
nylas otp watch agent@company.com

The watch command polls continuously and outputs new OTP codes as they arrive. For custom agent workflows, you can also use nylas otp get --raw in a loop with your own retry logic.

Handle magic link authentication

Some services skip codes entirely and send a magic link — a URL that authenticates the user when clicked. Agents need to extract these URLs from email bodies:

# Extract magic link from a login email
nylas email search "sign in" --from auth@app.com --limit 1 --json \
  | jq -r '.[0].body' \
  | grep -oE 'https://[a-zA-Z0-9./?=_-]+'  \
  | head -1

# Example output:
# https://app.com/auth/verify?token=abc123def456

The extracted URL can then be passed to a headless browser or HTTP client to complete the authentication flow. This is especially useful for agents that need to access web-only services that do not offer API keys.

Automate account recovery flows

Tokens expire. API keys get rotated. Passwords get reset. When an agent loses access to a service, the recovery flow almost always goes through email:

# After triggering a password reset on a service...

# Search for the reset email
nylas email search "password reset" --limit 1 --json

# Extract the reset link
nylas email search "reset" --from security@service.com --limit 1 --json \
  | jq -r '.[0].body' \
  | grep -oE 'https://[^ ]+reset[^ "]+' \
  | head -1

# Extract a temporary password
nylas email search "temporary password" --from noreply@service.com --limit 1 --json \
  | jq -r '.[0].body'

This gives agents self-healing capability. Rather than failing permanently when a credential expires, the agent can initiate recovery, read the reset email, and restore its own access.

Verify domain ownership

Services like DNS providers, email platforms, and CDNs often require domain verification via email. They send a confirmation to an address on the domain (e.g., admin@yourdomain.com). An agent managing infrastructure needs to read these:

# Check for domain verification emails
nylas email search "domain verification" --json

# Read the specific verification message
nylas email read msg_verification123 --json \
  | jq -r '.body'

Use MCP for interactive identity flows

When running through an MCP-compatible assistant like Claude, the identity flow becomes conversational. The assistant can coordinate the entire signup and verification process:

# Install MCP for your assistant
nylas mcp install --assistant claude-code

# Then ask your assistant:
# "Sign up for the Acme API using my email, then find the
#  verification code in my inbox and complete the signup."
#
# The assistant will:
# 1. Use list_messages to check for the verification email
# 2. Extract the code from the message body
# 3. Report back with the code for you to complete the flow

The MCP approach adds human-in-the-loop safety. The assistant shows you what it found and asks for confirmation before taking action — useful when the identity flow involves sensitive accounts.

Receive service notifications via inbound email

Many services send operational notifications via email: deployment status, error alerts, billing warnings, certificate expirations. An agent that monitors these can react automatically:

# Monitor for deployment notifications
nylas email search "*" --from deploy@ci-service.com --limit 5 --json \
  | jq '[.[] | {subject, date, snippet: .snippet}]'

# Check for certificate expiration warnings
nylas email search "certificate expiring" --json

# Set up an inbound webhook for real-time processing
nylas inbound create alerts@yourdomain.com

The nylas inbound create command sets up a webhook that fires whenever an email arrives at the specified address. This lets agents react in real-time rather than polling.

Parse structured data from identity emails

Beyond codes and links, identity emails often contain structured information: API keys, account IDs, onboarding instructions. Here is how to extract specific patterns:

# Extract an API key from a welcome email
nylas email search "welcome" --from team@api-service.com --limit 1 --json \
  | jq -r '.[0].body' \
  | grep -oE 'sk_[a-zA-Z0-9]{32,}'

# Extract an account ID
nylas email search "account created" --limit 1 --json \
  | jq -r '.[0].body' \
  | grep -oE 'Account ID: [A-Z0-9]+' \
  | head -1

# List all emails from identity-related senders
nylas email list --json \
  | jq '[.[] | select(.from[0].email | test("noreply|auth|security|verify")) | {from: .from[0].email, subject, date}]'

Security considerations for agent identity

Letting agents handle identity flows requires guardrails:

• Scoped access — Authenticate only the accounts the agent needs. Each nylas auth login creates a separate, revocable grant.
• Audit everything — Use nylas audit to log all agent email access. Review what identity emails the agent read and when.
• Time-box verification — Do not let agents poll indefinitely. Set timeouts on verification flows to prevent stale code usage.
• Never log credentials — Agent code should extract and use credentials (API keys, tokens) without logging them. Pipe directly to the next step.
• Separate agent and personal inboxes — Use a dedicated email account for agent identity flows, not your personal inbox.

Frequently asked questions

How quickly can agents find verification emails?

Search results are typically available within 1-5 seconds of the email arriving. For time-sensitive OTPs, poll every 3-5 seconds with a 60-second timeout. Most verification emails arrive within 10-30 seconds.

Can agents handle CAPTCHA challenges during signup?

No. Email identity flows help with the verification step that comes after CAPTCHA. For services that require CAPTCHA during signup, the agent needs a browser automation tool (like Playwright) for the initial form submission, then Nylas CLI for the email verification step.

What about services that use SMS instead of email?

Some services offer email as an alternative to SMS verification. When both are available, email is more automatable. For SMS-only services, the agent needs a separate SMS integration.

How do I prevent agents from signing up for malicious services?

Use an allowlist of approved domains in your agent's logic. The Nylas CLI itself does not restrict which emails an agent can read — that control belongs in the agent's decision layer.

Next steps

• Why AI agents need email — the broader case for agent inbox access
• Email as memory for AI agents — search and reason over conversation history
• E2E email testing with Playwright — similar patterns for test automation
• Build an LLM agent with email tools — integrate these patterns into custom agents