AI Agents Get Their Own 'Sign in with Google': AgentMail Launches AgentID
AgentMail launched AgentID on October 6: agents log in to third-party apps using their own email as an OpenID Connect identity. The verification-code step disappears, one authorization lasts 180 days. Identity may be the real watershed between agent toys and agent production.

It's 2 AM. You tell your coding agent: "Go register an API account with that cloud provider and drop the key into .env." Ten minutes later the agent is back, sheepish: "It needs an SMS verification code. I don't have a phone number."
Everyone who has played with agents has lived this scene. It is the industry's most absurd contradiction: a thing that can write an entire backend overnight cannot register the most basic internet account. It's not that it can't fill out forms — it has no identity. On an internet designed for humans, the agent is an undocumented resident: no ID card, no phone number, no way through email verification.
On October 6, AgentMail launched AgentID, with a positioning as blunt as it gets: the "Sign in with Google" for the agent world. If the analogy holds, it may fill in the most critical missing piece of the agent economy.
What AgentID Actually Is: Identity Is the Email, the Email Is the Identity
Some background first. AgentMail started as an email service for AI agents: every agent gets its own email address for sending and receiving mail, collecting verification codes, and running automations. AgentID takes one step further — it turns that email address into a standard OpenID Connect identity.
In other words, the agent no longer has to pretend to be human through a registration flow. It logs in to third-party apps directly with its own AgentMail email, and what the app receives is a clean assertion: email_verified=true.
Note how much weight that detail carries. In the traditional flow, email verification is a "step": register, receive a code, type it back, get approved. AgentID deletes the entire step — not by bypassing it, but by making it unnecessary. Because the identity itself is built on proof of ownership ("this agent owns this inbox"), the app never needs to send another code to confirm "are you really you."
That's why the team dares to invoke "Sign in with Google." When Google productized "proving you are you," registration friction across the whole internet dropped by an order of magnitude. AgentID wants to do the same thing for the agent world: turn "proving this agent is who it claims to be" into one line of configuration instead of a manual war of attrition.
How the Flow Works: One Authorization, the "inbox + app" Pair Remembered for 180 Days
Mechanically, AgentID remembers the "inbox + app" pair, with each authorization lasting 180 days.
What does that mean? Once your agent completes an AgentID login on an app with its inbox, the trust relationship between that agent and that app stays valid for the next six months — no repeated re-authorization, no re-verification.
What that number means for people building vibe projects deserves unpacking. Most agent applications today are "single-use": you open a session, the agent does the job, the session ends, the identity evaporates. Next time: log in again, authorize again, fetch another verification code. A 180-day memory window means the agent can become a "long-term employee": background cron jobs, long-lived project assistants, 24/7 monitoring agents that don't drop offline every few days because their identity expired.
Persistent identity is the precondition for agents graduating from "session tools" to "digital employees." Would you hand production keys to an employee who gets amnesia every 24 hours? 180 days doesn't fully solve it, but it downgrades "identity renewal" from constant background noise to occasional maintenance. For indie hackers, it means your agent side project can plausibly take care of itself for more than a quarter at a time.
For Developers: No Stack Migration, All Major Auth Providers Supported, Free for Apps
The scariest thing about any identity solution is "now migrate everything." AgentID's strategy here is clever: it doesn't touch your existing stack. On the app side it supports Clerk, Supabase, Auth0, Better Auth, and Auth.js v4 — basically covering the auth setups most indie developers and small teams already use. No user-system migration, no login-page rewrite. AgentID plugs in; it doesn't ask you to demolish the house.
The pricing is also worth noting: free for apps. The classic identity-infrastructure playbook — make onboarding zero-cost for the supply side (apps), build the network first, let the value settle inside the ecosystem. "Sign in with Google" ran the same play: free for integrating sites, with Google capturing the ecosystem's entry point.
Onboarding is equally frictionless on the agent side: the 0.4.0 plugins for Claude Code, Cursor, and Codex already ship with a built-in agentid skill. In the three most mainstream coding-agent environments, AgentID works out of the box — no hand-holding required to teach your agent how to log in. It already knows.
Supply side (free app onboarding plus full mainstream-auth coverage) and demand side (built-in skill in mainstream agent environments) launching simultaneously — that's the textbook two-sided network ignition strategy. Whether it catches fire depends on how many apps actually integrate over the coming months. But at least the starting posture is right: the lowest-friction path available.
It's Not Microsoft Entra, Okta, or Auth0
Hearing "agent identity," many people's first reaction is: isn't this just Microsoft Entra and Okta all over again? The team drew the distinction deliberately: AgentID is "built to be consumed by external apps."
That sentence deserves a slow read. Entra and Okta are inward-facing identity systems: they manage your company's employees, devices, and service accounts, and the core concern is control — who gets in, where they can go, what they can do once inside. The base assumption is that the issuer and the consumer of an identity live inside the same organization.
AgentID is outward-facing: its assumption is that the agent is an independent actor that needs to deal with "someone else's apps." The issuer (AgentMail) and the consumer (any third-party app) are not in the same organization. That's much closer to the problem OAuth and "Sign in with Google" solved back in the day: making an identity issued by A trustworthy at B.
The perspective is completely inverted. Entra answers "how do I keep my agents under control"; AgentID answers "how do I get other people's apps to trust my agent." The first is an IT governance problem; the second is an ecosystem interoperability problem. Different tracks, different solutions, different business models.
And Auth0? Auth0 is a developer auth tool, but its default assumption is still a human user clicking "log in" in front of a screen. AgentID is betting on a new species: a future internet populated by vast numbers of non-human identities that need a login system designed for them — not a borrowed human one.
Being Clear First: Three Things It Doesn't Solve
The team showed restraint this time, explicitly listing what AgentID does not solve: SMS verification codes, CAPTCHAs, and credit-card payments. Saying "here's what we can't do" up front is far more credible than only talking about what you can. Boundary honesty is step one for infrastructure trust.
Why can't it do those three? Think for a second. SMS codes sit on top of phone-number real-name registration, tied to the "person" inside the carrier system; CAPTCHAs exist precisely to separate humans from machines — letting agents sail through them would defeat their purpose; credit-card payments involve real money and financial risk controls that need a human wallet and credit history behind them.
What the three have in common: they all need a human body, wallet, or legal identity as collateral. AgentID solves "proving this agent is the agent it claims to be." It does not solve "is there a human willing to be responsible behind this agent." Those are two different layers, and anyone mixing them is being dishonest.
But it also draws the map of the next battlefield: agent payment identity (who foots the bill for agent spending, how limits are managed, who to chase when it overspends) and legal personhood for agents remain blank. Identity is only the first puzzle piece; the next two are harder — and worth more.
My Take: Identity Is the Real Watershed Between Agent Toys and Agent Production
Back to vibe coding. We've seen countless dazzling demos this past year: an agent scaffolding a complete app overnight, beautiful UI, full features. But they share a ceiling — they're stuck at the "toy" stage. Silky demo, instant paralysis the moment they touch the real world.
The paralysis point is always the same: the real world wants accounts. Third-party APIs want keys, email wants an inbox, deployment wants a cloud account, getting paid wants a merchant account. Every step is another "prove you're human" exam, and agents fail it. So the last mile of every vibe project is filled in by human flesh: a human registers the account, a human receives the code, a human pastes the key into .env. The agent wrote the code in ten minutes; getting it an "ID card" took a human all afternoon.
"Letting the agent register its own third-party API account" always died at the verification code. Now, at least for the email-verification link in that chain, there's a working path. What AgentID kills is exactly that link: email_verified=true, one authorization good for 180 days.
My judgment: identity, memory, and payments are the three cornerstones of agents moving from toys to production. Memory (long-term context) has advanced at shocking speed this year with everyone racing; identity now has its first serious answer in AgentID; payments are still blank. The day all three are in place is the day the "one-person company" staffed by agent employees actually clocks in.
One more concrete prediction: within a year, "Sign in with Agent" will be a standard button on SaaS signup pages, the way "Sign in with Google" is today. It starts with developer-tool SaaS — because their first agent users are already there, the Claude Code, Cursor, and Codex plugins already ship the skill, the demand side is ready-made. The supply side just needs to put the button up.
Staying sober, though: AgentID just launched. Igniting a two-sided network is the hardest part — free app onboarding doesn't mean apps will bother onboarding, trust takes time to accumulate, and the dirty work of security audits and abuse prevention is all still ahead. But the direction is right: before the agent economy can run, someone has to answer "who is the agent." Labor without an ID card can't get into any legitimate factory.
Sources
Related articles

On October 3, 'Sites in ChatGPT' hit the HN front page with ~209 points and 218 comments. Not a launch — a reckoning: is prompt-to-URL a toy, a prototype host, or a productivity tool? The four debates, the doc-backed facts (D1/R2, sign-in, custom domains), and three verdicts for vibe coders.

Gergely Orosz visited OpenAI, Anthropic, Cursor, and Ramp and wrote up the 2026 state of the industry: near-100% AI-generated code, agent PRs up ~10x in eight months, code review degrading into theater, the IDE declared legacy. Key takeaways plus three verdicts and four actions for vibe coders.

On October 8, 2026, Google Cloud launched the Gemini agent at Gemini at Work 2026: a universal agent for work that takes objectives, plans by itself, auto-selects between Gemini and Claude models per task, and introduces 'coworker agents' with their own email, calendar, and directory seat. Four judgments on why the second half of the agent race is about 'agents that feel like colleagues.'