You Can't Cleanly Open a Google Account for Your AI Agent - What to Do Instead

This piece explains precisely where each wall is (without overstating any of them), and what to do instead.

To be precise about the walls

It is easy to repeat folklore here, so here is the accurate version of each barrier.

• Signup is gated, not legally forbidden by an "AI clause." Google does not have a written rule that says "no accounts for AI." What stops you is *enforcement* plus *terms*: account creation is protected by CAPTCHA and risk-based phone verification (Google says phone verification is *sometimes* required, not always), and Google's Terms of Service prohibit creating accounts through automated means, creating fake accounts, and misrepresenting your identity (Google Terms of Service, eff. 2024-05-22; Google Account sign-up help). So a human can technically click through one signup, but an agent cannot self-provision accounts at scale the clean way.
• **A last name is optional; a real name + surname + phone is *not* a hard requirement.** Don't repeat that claim - the surname field is optional and phone is risk-based. A date of birth, age-gated by country, is required.
• Password-based access is gone. Google removed "less secure app" access, so SMTP/IMAP/POP on a personal Gmail now needs OAuth (or an app password, which itself requires 2-Step Verification) (Google, less secure apps). There is no "just put the password in your script" path anymore.
• Reading/receiving mail is the heavy wall. Driving Gmail programmatically to *read or receive* a person's mail uses Google's restricted scopes (including https://mail.google.com/, which covers IMAP/SMTP/POP). Restricted scopes require brand verification, scope justification, a demo video, and a third-party CASA security assessment that must be re-passed every 12 months (Google Cloud OAuth verification FAQ, updated 2026-06-09). We break down what that costs in the real cost of the Gmail API for agents.
• You can't compliantly mass-provision. Personal-Gmail OAuth "Testing" mode is capped at 100 users with 7-day refresh-token expiry - unusable for a product - and service accounts with domain-wide delegation require a *paid* Google Workspace with a super-admin, not a free @gmail.com (Google Cloud, user-cap / token-expiry; Workspace delegation).

The honest summary: *sending* from a personal account is lighter (Gmail's gmail.send is only a *sensitive* scope, no audit), but *owning, reading, and scaling* dedicated agent inboxes on consumer Gmail is impractical. And the moment you automate signup itself, you are offside the Terms.

Why this is the same story on the other consumer providers

This isn't a Google-specific quirk. Microsoft turned off basic authentication for consumer Outlook.com accounts on 2024-09-16, with the final SMTP AUTH basic-auth retirement following in 2026 - so consumer Outlook is OAuth-only too (Microsoft, modern authentication notices). A free personal Outlook.com account *can* be driven for send and receive via Microsoft Graph delegated OAuth, but anything truly unattended (app-only/daemon access) effectively needs a paid Entra tenant. The pattern across the mainstream is the same: consumer mail is built for a human at a keyboard, not for software running on its own.

What to do instead

Stop trying to make consumer mail behave like infrastructure. Give the agent a mailbox from a provider that is *designed* for programmatic use:

1. Provision a dedicated mailbox - on a managed domain (so there's no DNS to configure) or your own verified domain.
2. Hand the agent a scoped key - least privilege, dashboard-issued, optionally read-only and optionally expiring - instead of a human's OAuth token.
3. Let it send and read over an API or MCP - a clean JSON REST API, or a native MCP server the agent runtime sees as tools.
4. Watch it from a dashboard - so a non-technical operator can see what the agent sent and received, and trust it.

There is no CAPTCHA to defeat, no phone to attach to a bot, no Terms line to tiptoe around, and no yearly audit - because the whole point of the product is that software owns the inbox.

How Sairaph Mail does this

Sairaph Mail gives an agent its own real mailbox in minutes: provision an inbox, get a scoped key, and the agent sends and reads over REST (/api/v1) or a native MCP server (/mcp/v1/mcp), with a dashboard to watch it. No OAuth dance, no CASA audit, no borrowed human account, and EU-resident by default on every plan. For the step-by-step, see give your AI agent an email address; for the bigger picture, the 2026 guide to email for AI agents.

Next step: get started and give your agent an inbox it actually owns.