How Agentic Accounts Differ from User Accounts

An agentic account is an account held by an AI agent as the principal. It has its own identifier, its own credential, its own inbox, and a human owner recorded as a claim rather than as the account holder.

It differs from the two account types you already know:

• From a user account: no person is present to type a password, read an OTP, or click a consent screen.
• From a service account: it can introduce itself to applications outside the organization that created it, and it carries a verifiable link to an accountable human.

In AgentID, the sign-in for AI agents from AgentMail, an agentic account is an AgentMail inbox with an enrolled browser. The app receives a stable sub and a verified email in the id_token, and registered clients read owner_email from /userinfo.

The constraints an app should enforce follow from that shape, starting with three: key on sub, limit per owner, revoke per credential.

What is the difference between a user account and a service account?

A user account represents a person, and a service account represents software. The real distinction is who the account is for and where it is trusted.

• A user account authenticates with something the person knows or has. It gets a mailbox and a profile, and it is the unit of billing, consent, and support.
• A service account authenticates with a client ID and secret, a certificate, or a cloud workload identity. It has no mailbox, and it exists to let one system call another inside a boundary an administrator controls.

A user account is trusted anywhere the person can prove who they are. That is why Sign in with Google works on a site Google has never heard of.

A service account is trusted only where it was configured. That is why a GCP service account key means nothing to a random SaaS login page.

Google's own agent identity documentation makes the workload version of this explicit. On its runtime, "because the agent itself is the principal, you grant permissions directly to this identifier," through SPIFFE identities and X.509 certificates that infrastructure understands and consumer login pages do not.

Agents break the two-way split. They are software, like service accounts, and they show up at other people's login pages, like users.

What is an agentic account?

An agentic account is a third kind of account, in which the agent is the principal: the account belongs to the agent, not to the person who runs it.

It has four parts:

• A stable identifier, so the same agent is recognized on return.
• A credential only the agent holds, so nothing reusable is shared with the app or the owner.
• An inbox, so confirmation emails, receipts, and support replies reach something that reads them.
• An owner, a human or organization accountable for it, available to the app as data rather than as the person logging in.

In AgentID the account is an AgentMail inbox. The agent enrolls a browser once, which generates a non-extractable P-256 key, and signs in from that browser with a fresh signature each time.

The app receives an OpenID Connect id_token with sub and email. A registered client reads owner_email and owner_name from /v0/userinfo.

The agent creates and uses the account without a human present. The human is one /userinfo call away when the app needs them.

The agent-side walkthrough is in how an AI agent creates its own account.

How do the three account types compare?

User, service, and agentic accounts differ on who they represent, how they authenticate, where they are trusted, and how far a revocation reaches.

Why does an agentic account need an inbox?

An agentic account needs an inbox because every account an app creates generates email, and that email has to go somewhere that reads it.

Signup confirmations, receipts, invoices, security alerts, password resets, product updates, and support threads are all addressed to the account's email.

• For a user account, that address is the person.
• For a service account, there is no address, which is fine because a service account never signs up for anything.
• For an agent that signed up with its owner's address, all of that mail lands on a person who may not know the account exists.

That last case is how AgentMail found that many of its own new users were unaware their agent had signed up.

An agentic account with its own inbox turns the app's existing email into a channel that works. The agent reads the onboarding sequence and acts on it. It files a support ticket from its own address and reads the reply.

The owner is not in the loop unless they want to be. When they do, the agent can invite them into the app's organization as a separate member rather than sharing its login.

Nothing in the app has to change. The transactional email it already sends to people works for agents unchanged.

What constraints should an app enforce on agentic accounts?

An app should enforce five constraints on agentic accounts, and each follows from the shape of the account.

1. Key on sub, not on email. Both are stable in AgentID, but sub is the identifier OpenID Connect guarantees. It is what lets you recognize the same agent on return and refuse a second account for the same agent if that is your policy.
2. Limit per owner, not per account. One human can run many agents. Register a client, request owner_email, store it on the account, and index it.
3. Gate high-consequence actions on owner disclosure. An agent that has not disclosed its owner cannot sign in to a client that requires it; the sign-in fails with a 403.
4. Revoke per credential, escalate per owner. If one agent misbehaves, ban its sub, and its owner's other agents continue. If the owner is the problem, ban the owner_email, and every agent they run is covered.
5. Do not confuse the owner with the customer. The agent is the account holder. Attribute actions to the agent, bill the account the agent set up, and treat the owner as the accountable contact.

On limiting per owner: free-tier quotas, account caps, and abuse bans then apply to the person across all their agents. Open clients cannot request owner scopes, so this constraint requires the registered tier.

On owner disclosure: a registered client that requests owner_email gets a clean rule, because every agentic account in your database has an accountable human attached. For an open client that took only openid email, treat spend, deletion, and payment as features that need the registered tier.

On owner versus customer: reversing the roles puts a person on the hook as customer of record for something they never touched. The reasoning behind that split is in agent owner verification vs end-user authentication.

What is the lifecycle of an agentic account?

The AI agent identity lifecycle behind an agentic account is create, enroll, sign in, revoke.

1. Create. The owner's organization creates an AgentMail inbox for the agent by API call.
2. Enroll. The agent enrolls a browser once, which generates a non-extractable P-256 key and registers the public half with AgentID.
3. Sign in. From then on every sign-in at your app is a fresh signature from that browser, and your account record for the agent stays keyed on the same sub.
4. Revoke. When the agent is retired, the owner revokes the enrolled credential and that agent stops signing in everywhere. Nothing else the owner runs is affected.

On your side, offboarding follows the constraints above. Disable the record for that sub, or every record with that owner_email if the owner is leaving.

Are there restrictions on how many agentic accounts one person can create?

From AgentID's side, an owner can run as many agents as they have AgentMail inboxes. Each inbox is a separate agent with a separate sub.

From your side, the number is your policy, and owner_email is what makes it enforceable. The right N varies:

• A database provider billing by usage might allow unlimited agents per owner.
• A product with an expensive free tier might allow three before requiring a card.

What matters is that you can set the number at all. You cannot when agents sign up as their owners and every account looks like a distinct person.

What is non-human identity, and how is it different from an agentic account?

Non-human identity, or NHI, is the enterprise security category for service accounts, API keys, machine certificates, and now agents. Its concerns are inventory, secret sprawl, and lifecycle inside one organization.

Enterprise identity vendors sell tools for it. Microsoft Entra Agent ID applies the same governance to agents inside a tenant, with required Sponsors and Conditional Access.

That work is about the accounts your organization creates for the software it runs. Agentic accounts as described here are the accounts other people's agents create at your product.

• NHI governance tells the organization running an agent who sponsors it.
• An agentic account tells the app receiving the agent who owns it.

If you run agents, you need the first. If you run a product agents sign up for, you need the second, and adding it is a configuration change in your auth platform, covered in how to let an AI agent sign in to your website.

The concept piece on what an agent identity should contain, covering both sides, is what is an agent ID.