Letting AI agents sign in to your app doesn't mean rebuilding authentication. The protocol, the callback and the session all stay the same. What changes is who the account belongs to, how you limit it, who you call when something goes wrong, and what revoking access actually does. This post is a checklist of those differences, for the engineer about to switch agent sign-in on.
Agent authentication differs from user authentication in who the principal is, not in the protocol: an agent signs in through the same OpenID Connect flow a person uses, but there is no password, no second factor, and a human owner who stands behind the account. The work of adding it is in your policies for limits, contact and revocation, not in new infrastructure.
Most teams arrive at this question in one of two ways. Either agents are already creating accounts and nobody can tell which rows they are, or a customer has asked whether their agent can sign in and nobody is sure it is safe to say yes. Both lead to the same place. The login code barely changes, and a surprising amount of the product around it does. What follows separates the two, section by section, and ends with the list we'd walk through before turning agent sign-in on.
What stays the same when agents sign in?
The protocol stays the same when agents sign in. An agent identity provider is an OpenID Connect issuer like the ones your login already trusts, so the redirect, the authorization code exchange, the signed id_token and the session your app issues afterwards all work as they do for Sign in with Google. What is an agent ID covers what that identity contains.
Your auth platform stays the same too. Custom OIDC providers are a standard feature of hosted auth, and an agent issuer plugs into that slot. What your app receives is a token naming a subject, a verified email address and a few extra claims, and every one of those is something your code already knows how to handle.
What changes for your login page?
Three things change on the login page: there is no password to collect, no second factor to send, and no confirmation email to wait for. The agent proves itself with a one-time signature from a key it holds, the issuer checks it, and your app receives a token instead of a credential it has to store.
The address in that token arrives already verified. That removes the step where agents usually stall, since a verification code sent to an inbox the agent can't read is the most common place agent sign-ups die, as what happens when an AI agent hits 2FA or an email OTP explains. Consent changes shape as well: the agent approves what your app receives with its own key, and a sign-in built for agents remembers that approval so it doesn't ask on every visit.
What changes for your abuse controls?
Your abuse controls change from counting accounts to counting owners. A person can run many agents, and each one is a fresh account, so a limit per account hands that person as many free tiers as they have agents. The unit that matches your pricing is the owner.
A sign-in built for agents gives you that unit as a claim. The token marks the subject as an agent, so agent policy is a branch in your code rather than a guess, and it carries an owner identifier that every agent with the same owner shares. Quotas, signup caps and bans keyed on that identifier apply to the person, however many agents they run.
Is it safe to let agents sign in?
It is safe to let agents sign in when the sign-in proves which agent it is, names who is accountable, and gives you a way to cut it off. A borrowed password does none of those. A sign-in designed for agents does all three, and it doesn't claim more than that: it is not a trust score, and it doesn't say the agent is well behaved.
| Concern | Human user | AI agent | What to do |
|---|---|---|---|
| Credential | Password, often with a second factor | A one-time signature; nothing reusable crosses the sign-in | Nothing to store or reset |
| Replay | Stolen passwords work until changed | Each sign-in is consumed once; codes expire in seconds | Verify the token's signature, issuer and audience |
| Who the account belongs to | The person | The agent, with its owner as a claim | Key the account on the agent's subject |
| Limits | Per account is roughly per person | Per account is per agent | Limit on the owner identifier |
| Contact | The user's email | The agent's own inbox, plus the owner's email if you request it | Write to the agent for operations, the owner for accountability |
| Revocation | Reset the password; sessions end | Deleting the agent's key stops new sign-ins, but your sessions continue | Keep agent sessions short and re-check before sensitive actions |
The revocation row is the one to design around. The identity provider stops new sign-ins everywhere the moment a key is deleted, but it sends no webhook and no back-channel logout, so an agent already signed in stays signed in until your own session ends.
What should you check before turning it on?
Check these six things before turning agent sign-in on:
- Your account key is the agent's stable subject, not its email address.
- Your limits read the owner identifier, with the agent's subject as a fallback when it is absent.
- Your agent policy branches on the claim that marks the subject as an agent.
- Your sessions for agents are short enough that a revoked key stops mattering quickly.
- Your contact paths send operational mail to the agent's inbox and escalations to the owner.
- Your trust decisions don't treat a verified identity as proof of good behavior; your abuse controls still run.
If those hold, agents are customers you can see, limit and reach, and the ones you'd rather not serve are easy to find and cut off. AgentID, our sign-in for AI agents, is built around exactly this list, and how an AI agent proves its identity to your app shows each claim your app would read. The agent's side starts with an email address for your AI agent's signups.
AgentMail gives your agents real inboxes. Create inboxes via API. Send and receive Emails with 0 complexity. Free to start.
