Guide

Why AI Agents Need Email Addresses

Email is the internet's de facto identity layer. According to Auth0's 2024 Identity Report, 94% of web services use email for registration. When AI agents interact with these services autonomously, they need inbox access for signups, OTP verification, agent-to-agent communication, and identity trust chains. Works across all major email providers.

Written by Nick Barraclough Product Manager

Reviewed by Qasim Muhammad

Verified — CLI 3.1.1 · Gmail, Outlook · last tested April 11, 2026

Why email is the identity layer

Email serves as the internet's de facto identity layer because virtually every web service requires an email address for registration, verification, and account recovery. According to Auth0's 2024 Identity Report, 94% of web services use email-based authentication. For AI agents operating autonomously, inbox access is the prerequisite for interacting with any of these services.

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

OTP (one-time password) verification is the most common email-based identity flow. A service sends a 4-8 digit code to an inbox, and the recipient must enter it within a short window — typically 5 to 10 minutes. According to Twilio's 2023 Account Security Report, 65% of businesses use email OTP as part of their authentication pipeline.

Nylas CLI provides a dedicated otp command that scans recent messages, identifies verification codes, and returns the result in one step. The command supports piping with --raw for automated agent workflows:

# 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 identifies OTP patterns from verification senders and extracts the code — no jq, no regex, no manual parsing. It also copies the code to the clipboard automatically.

Watch for incoming verification codes

Verification emails arrive with variable latency — most land within 10 to 30 seconds, but some providers take up to 2 minutes. An AI agent that triggers a signup and immediately queries the inbox will miss the code. The otp watch command solves this by polling continuously and printing new codes as they arrive.

By default, otp watch checks every 10 seconds. For time-sensitive OTPs with short expiry windows (some services set expiry as low as 60 seconds), a faster polling interval reduces the risk of the code expiring before the agent captures it:

# 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

For custom agent workflows, nylas otp get --raw can be called in a loop with custom retry logic and a timeout ceiling.

Magic link authentication replaces numeric codes with a single-use URL that grants access when opened. Services like Slack, Notion, and Medium use magic links as their primary passwordless login method — Slack alone reports that over 750,000 organizations use this pattern. For AI agents, extracting the URL from the email body and passing it to an HTTP client completes the authentication flow without manual interaction.

The Nylas CLI email search command retrieves the message body, and standard Unix tools extract the URL. Magic links typically expire within 10 to 15 minutes, so agents should process them promptly after retrieval:

# 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 be passed to a headless browser or HTTP client to complete the authentication flow. This pattern is especially useful for agents that need to access web-only services that don't offer API keys.

Automate account recovery flows

Account recovery is the safety net that keeps AI agents operational when credentials fail. Tokens expire (OAuth2 access tokens typically last 3,600 seconds), API keys get rotated, and passwords get reset. According to NIST SP 800-63B, email-based account recovery is the most widely implemented self-service recovery mechanism on the web. When an agent loses access to a service, the recovery flow almost always routes through the inbox.

Nylas CLI's email search command lets agents find reset emails by sender and keyword, then extract reset links or temporary credentials using jq and grep:

# 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 pattern gives agents self-healing capability. Rather than failing permanently when a credential expires, the agent initiates recovery, reads the reset email, and restores its own access — all without human intervention.

Verify domain ownership

Domain ownership verification confirms that an entity controls a specific domain by sending a confirmation email to an address like admin@yourdomain.com or webmaster@yourdomain.com. DNS providers, email platforms, CDNs, and certificate authorities all use this flow — Let's Encrypt alone issues over 4 million certificates per day, many requiring email-based domain validation. An AI agent managing infrastructure needs inbox access to complete these verification steps automatically.

The Nylas CLI email search command filters for domain verification messages, and email read retrieves the full message body containing the confirmation link or code:

# 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

The Model Context Protocol (MCP) enables AI assistants to call external tools during a conversation, turning identity flows into interactive, human-supervised workflows. Instead of scripting each step, the assistant coordinates signup, code retrieval, and verification as a guided conversation. MCP support is available in Claude Code, Cursor, and other MCP-compatible clients — over 15 editors and assistants support the protocol as of early 2026.

After installing the Nylas MCP server, the assistant gains access to email tools like list_messages and can extract verification codes conversationally. The human-in-the-loop model means the assistant shows what it found and asks for confirmation before proceeding:

# 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 is especially useful when identity flows involve sensitive accounts where autonomous action would be too risky.

Agent-to-agent communication via email

Email is the only universal, open, federated messaging protocol on the internet, making it the natural medium for agent-to-agent communication. An agent at Company A can email an agent at Company B without any API integration, shared platform, or mutual authentication setup. SMTP has operated continuously since RFC 821 was published in 1982 — over 40 years of backward-compatible infrastructure. The email protocol handles routing, delivery confirmation, and sender verification (via SPF, DKIM, and DMARC) automatically.

Three patterns work well for machine-to-machine email:

  • Structured payloads in email bodies: Agents send JSON or YAML in the email body. The receiving agent parses it with nylas email read --json | jq '.body'.
  • Subject line as routing key: A consistent subject prefix like [AGENT-REQUEST] lets the receiving agent filter for machine-to-machine messages.
  • Reply threading for conversations: Agents maintain multi-turn conversations using thread IDs. The --reply-to flag keeps messages in the same thread.

The following example shows Agent A sending a JSON payload to Agent B, and Agent B querying its inbox for incoming agent requests. The --yes flag skips the send confirmation prompt, which is required for fully autonomous agents:

# Agent A sends a structured request to Agent B
nylas email send \
  --to "agent-b@partner.com" \
  --subject "[AGENT-REQUEST] Invoice data for Q1 2026" \
  --body '{"request_type": "invoice_export", "quarter": "Q1-2026", "format": "csv"}' \
  --yes

# Agent B listens for agent requests
nylas email search "[AGENT-REQUEST]" --json --limit 5 | jq '
  [.[] | {
    from: .from[0].email,
    request: (.body | fromjson? // {error: "not JSON"}),
    received: .date
  }]'

Verify agent identity through email

Agent identity verification uses the same cryptographic infrastructure that protects human email: SPF, DKIM, and DMARC. These three protocols, defined in RFC 7208, RFC 6376, and RFC 7489 respectively, let a receiving agent confirm that a message genuinely originated from the claimed sending domain. According to Google's 2024 Email Security Transparency Report, over 90% of inbound Gmail traffic now passes DKIM validation, making it a reliable trust signal.

An agent sending from a domain with a p=reject DMARC policy can be trusted to be who it claims. The Nylas CLI email read command exposes authentication headers for programmatic inspection:

nylas email read msg_from_agent --json | jq '.headers["authentication-results"]'
# Look for: dkim=pass, spf=pass, dmarc=pass

Receive service notifications via inbound email

Operational notifications — deployment status, error alerts, billing warnings, certificate expirations — still flow through email at most organizations. A 2023 PagerDuty survey found that 78% of incident response workflows include an email notification step. AI agents that monitor a dedicated inbox for these messages can trigger automated responses: scaling infrastructure after a deploy, opening tickets after error alerts, or renewing certificates before expiry.

Nylas CLI supports both polling-based search and real-time webhook delivery. The email search command works for periodic checks, while webhook create fires an HTTP callback whenever new mail arrives in the monitored inbox:

# 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

# Provision a managed agent inbox for the alerts identity
nylas agent account create alerts@yourdomain.com

# Subscribe to real-time inbound delivery
nylas webhook create \
  --url https://example.com/hook \
  --triggers message.created

The nylas agent account create command provisions a managed inbox under provider=nylas; the webhook fires whenever an email arrives. This lets agents react in real-time rather than polling.

Parse structured data from identity emails

Identity emails contain more than verification codes and links. Welcome emails, provisioning confirmations, and onboarding messages embed structured data — API keys, account IDs, workspace URLs, and configuration instructions. Stripe's welcome email alone contains 3 distinct API keys (publishable, secret, and restricted), each following the pattern sk_test_ or pk_test_ with a 24+ character suffix.

The Nylas CLI email search command retrieves message bodies as JSON, and standard Unix tools like grep extract specific patterns. This approach works across any email provider without provider-specific API calls:

# 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

Granting AI agents access to identity emails introduces risk — a compromised agent with inbox access could reset passwords, intercept OTP codes, or exfiltrate API keys. According to OWASP's Top 10 for LLM Applications (2025 edition), excessive agency ranks as the #8 vulnerability. Five guardrails reduce this attack surface to an acceptable level:

  • 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