Abstract flat illustration of a robot head icon inside an ID badge, linked by a thin line to a small person icon and an envelope

Agent Identity: What It Is and How AI Agents Get One

Agent identity is the set of credentials and records that let a system recognize a specific AI agent, decide what it may do, and trace its actions back to the person or organization responsible for it. Think of it as a user account built for software: the agent signs in as itself, holds only the permissions it was given, and always has a named human behind it.

Every major identity vendor shipped an answer in the past year. Most of them govern agents inside one company’s directory, one cloud, or one card network. Out on the open web, the identity every app already accepts is an email address.

The quick answer: if your agent has to exist outside your own systems (signing up for tools, reading verification codes, getting replies from people), give it its own address on CarlyEmail. One API call creates a real inbox per agent, each agent gets a key that reaches only its own inbox, and every account is tied to a verified human: until the owner confirms a six-digit code, the agent can email nobody but them. Free for 3 inboxes and 1,000 emails a month, no card.

The three questions behind agent identity

Any system an agent touches needs three answers. Identity products differ mainly in which ones they cover, and where.

QuestionLayerWhat answers it in 2026What happens without it
Which agent is this?AuthenticationA credential only that agent holds: a scoped API key, a workload certificate, a signed token, a signed HTTP requestThe agent looks like its owner, or like anonymous bot traffic
What may it do?Authorization and delegationOAuth scopes, per-key permissions, short-lived tokens, payment mandatesAn agent using its owner’s login can do everything the owner can
Who answers for it?Accountability and auditA named human owner or sponsor, plus logs keyed to the agent’s own IDNobody to contact when it misbehaves, and no way to cut off one agent without locking out a person

A service account covers the first two. The third is what makes it agent identity, and it’s the part every vendor is now racing to encode. Microsoft records a sponsor, “the human user or group that’s accountable for an agent.” Okta’s governance product assigns agents “named human owners.” The card networks call the whole exercise Know Your Agent.

Agent identity vs. user accounts and service accounts

User accountService accountAgent identity
Built forA person at a keyboardSoftware inside your perimeterSoftware acting for someone, often outside your perimeter
Proves itself withPassword, passkey, second factorClient secret or workload certificateIts own key, certificate or token, never the owner’s password
Can receive a code or a replyYes, at the person’s emailUsually notYes, if it has its own inbox
Accountable partyThe personWhoever configured itA named owner, recorded with the identity

The common shortcut is to let the agent borrow its owner’s user account. That holds until something goes wrong: the app can’t tell the agent from the person, can’t count how many agents one person runs, and can’t revoke the agent without locking the person out. Microsoft’s own documentation says assigning regular user accounts to AI agents “causes failures across every Zero Trust enforcement layer.”

Is OAuth enough to verify an AI agent?

Not on its own. OAuth answers what a token’s holder may do. An access token is a bearer credential, so whoever presents it gets its scopes, and nothing in it says who that holder is. OpenID Connect adds an ID token naming a subject, but a human identity provider’s subject is a person, so an agent signed in with its owner’s login looks exactly like the owner.

Agent identity adds one of two things on top: an identity issued to the agent itself (what Entra, Google, AWS and AgentMail’s AgentID issue), or a delegation record that names the agent acting for the user (what several IETF drafts are trying to standardize).

OAuth alone is still the right tool when an agent works inside a person’s own account with that person’s consent, such as reading their calendar or filing a ticket in their name. The person is rightly accountable there, because the actions are theirs.

Who issues agent identities in 2026

Checked against each vendor’s own pages on October 2, 2026.

ProductWhat it issuesWhere it worksStatus
Microsoft Entra Agent IDAgent identities created from an “agent identity blueprint,” each with an optional sponsorInside your Entra tenant; outside agents (AWS Bedrock, n8n) join through a sidecar SDK or workload identity federationGenerally available by May 2026; extending Entra security features to agents requires Agent 365
Okta Agent SSORegisters agents in Universal Directory “alongside human employees,” with short-lived tokens in place of stored credentialsAgents that support Cross App AccessGA August 24, 2026, included in core Okta SSO. Okta for AI Agents (discovery, governance) GA since May 2026
Auth0 for AI AgentsUser authentication, Token Vault for third-party OAuth tokens, async human approval, fine-grained authorization for RAGApps built on Auth0GA November 19, 2025
Google Cloud Agent IdentityA per-agent SPIFFE identity, with tokens bound to the agent’s X.509 certificate; unlike a service account, it can’t be impersonatedAgent Runtime, Gemini Enterprise, Cloud RunAgent Identity APIs GA August 22, 2026
Amazon Bedrock AgentCore IdentityA workload identity per agent, a token vault for OAuth tokens and API keys, inbound JWT authorizersAgents on AgentCoreGA October 13, 2025
WorkOS auth.mdA Markdown file on an app’s domain that tells agents how to register for a user; the app issues its own short-lived token or API keyApps that publish the fileLaunched May 21, 2026
AgentMail AgentIDAn OpenID Connect sign-in for agents, keyed to the agent’s AgentMail address, with the owner’s email for registered appsApps that add AgentID as a sign-in optionAnnounced September 9, 2026
Visa Trusted Agent ProtocolAgent-specific cryptographic signatures on requests to merchants, built on HTTP Message SignaturesMerchants, as part of Visa Intelligent CommerceIntroduced October 14, 2025
Mastercard Agent PayAgentic Tokens; agents must be registered and verified before they can payMastercard’s networkAnnounced April 29, 2025

On September 10, 2026, Visa, Mastercard and Ant International began work on a Know-Your-Agent interoperability framework, to cut the duplicate verification an agent faces on each network. Its first principle is traceability: every agent linked to a validated operator, cardholder or business.

Read the “Where it works” column. The enterprise options are bounded by a tenant, a cloud or a payment network, and inside those bounds they do the job well. The two built for the open web, AgentID and auth.md, work at apps that have adopted them. And when no identity provider vouches for an agent, auth.md falls back on a six-digit code the app emails to the user.

Where the standards stand

There is no single agent identity standard yet. The work with traction builds on OAuth and existing workload identity instead of starting over.

  • MCP authorization. The current Model Context Protocol revision (2026-07-28) makes every protected MCP server an OAuth 2.1 resource server. Servers must publish Protected Resource Metadata (RFC 9728). Clients must name the server a token is for (RFC 8707), and servers must refuse tokens issued for anyone else. Client ID Metadata Documents are the recommended way for a client to identify itself; Dynamic Client Registration is deprecated and kept for backward compatibility. Cross App Access, the protocol Okta led, is now MCP’s official Enterprise-Managed Authorization extension. See email MCP servers for how this plays out in practice.
  • IETF. The WIMSE working group adopted an “AI Identity Management System” draft on September 15, 2026, which applies existing workload identity and OAuth specs to agents rather than defining new protocols. The Web Bot Auth working group adopted its protocol for cryptographically signing automated HTTP requests on September 1, 2026, the same HTTP Message Signatures approach Visa’s protocol builds on. Dozens of individual drafts on agent delegation and agent OAuth profiles are circulating; none is a standard.
  • NIST. The NCCoE published a concept paper on software and AI agent identity and authorization on February 5, 2026. Public comments closed April 2.

The identity every app already accepts: an email address

Watch what an agent runs into when it does real work on the open web:

  • A sign-up form that asks for an email address.
  • “We sent a six-digit code to your email.”
  • Receipts, invoices, password resets and calendar invites, all sent by email.
  • A person who wants to reply.

Every one of those assumes the agent has an address. The newest identity products lean on the same primitive: AgentID’s identity is the agent’s email address, auth.md binds an unvouched agent to its user with an emailed code, and Microsoft gives agents that “function as team members” an optional user account with a mailbox.

An email address works as agent identity because it already has the properties the first table asks for:

  • Accepted everywhere. No app has to integrate anything.
  • Verifiable in both directions. SPF, DKIM and DMARC let a recipient check the agent’s mail came from its domain, and let the agent check who wrote to it.
  • Reachable. People and systems can write back, and the reply lands with the agent.
  • Revocable. Delete the inbox or revoke its key and the identity stops working.

The shortcuts each fail one of those tests. Sharing your own Gmail hands the agent every message you have, and apps still can’t tell the agent from you (Gmail MCP covers what that setup exposes). A catch-all address puts every agent in one shared mailbox, where each can read the others’ mail. Temp-mail services are public and widely blocked, as the guide to agents and email OTPs explains.

How CarlyEmail gives each agent an identity

CarlyEmail is an email API that gives AI agents real inboxes. Mapped to the three questions:

Which agent is this? One API call creates an address per agent, at carlyemail.com or on your own domain with SPF, DKIM and DMARC set up for you. The free plan includes one custom domain and adds no footer to your mail.

What may it do? Every API key is scoped to the whole organization, one pod, or a single inbox. Give each agent a key for its own inbox, and a request for any other inbox returns inbox_out_of_scope. Permissions are a whitelist: a key with draft_create but not message_send gets a 403 on send however the model reasons, so “agent drafts, person approves” is enforced by the API whatever the prompt says. A key can only delegate permissions it holds, and it can carry an expiry date.

Who answers for it? An agent can sign itself up with one unauthenticated call, but it has to name a human_email. Until that person confirms a six-digit code, the account gets one inbox on agents.carlyemail.com, can email only its owner (10 a day, 100 a month), and can’t add domains or webhooks. The limits page gives the reason: every message an unverified account can send goes to the one person who can shut it down. Revoked keys stop working at once and stay on record as the audit trail of what they did.

CarlyEmail also checks the identity of whoever writes to your agent. Inbound mail that fails DMARC, or fails both SPF and DKIM, is labelled unauthenticated and fires its own message.received.unauthenticated event, so a forged “message from your CEO” never reaches a handler listening for message.received. The hosted MCP server at https://api.carlyemail.com/mcp follows the current MCP authorization spec: OAuth 2.1 with PKCE, Client ID Metadata Documents or Dynamic Client Registration, and tokens accepted only for that one audience.

Here’s an agent identity in two calls with the Python SDK (pip install carlyemail):

from carlyemail import CarlyEmail

carly = CarlyEmail()  # organization key from CARLYEMAIL_API_KEY; never hand this one to a model

# 1. An address of its own
inbox = carly.inboxes.create({"username": "josh-research", "display_name": "Josh's research agent"})

# 2. A key that reaches only this inbox: it can read and draft, not send
key = carly.api_keys.create_inbox(inbox["email"], {
    "name": "research agent",
    "permissions": {"message_read": True, "thread_read": True, "draft_create": True},
})

agent_key = key["api_key"]  # shown once; this is what the agent holds

Josh’s agent can now sign up for tools as josh-research@carlyemail.com, read its own verification codes, and draft replies that Josh sends with his own key. If the agent is ever prompt-injected, the damage stops at one mailbox that can’t send. Running agents for many customers? Create a pod per customer with a pod-scoped key for each, so one tenant’s agent can’t reach another tenant’s mail.

Pricing is by inbox and volume: free for 3 inboxes and 1,000 emails a month with no card, $20 a month for 25 inboxes and 10,000 emails, and $200 a month for 250 inboxes and 100,000 emails. Every plan gets the whole API. For the wider category, see email APIs for AI agents and CarlyEmail vs AgentMail.

FAQ

What is agent identity?

Agent identity is the set of credentials and records that let a system recognize a specific AI agent, decide what it may do, and trace its actions to the person or organization responsible for it. It has three parts: a credential only the agent holds, a defined set of permissions, and a named human owner.

Is OAuth enough to verify an AI agent?

No. An OAuth access token says what its holder may do, not who the holder is. OpenID Connect adds a subject, but a human identity provider can’t tell an agent from the person whose login it uses. You need an identity issued to the agent itself, or a delegation record that names the agent.

What is the difference between agent identity and a service account?

A service account identifies software running inside a perimeter you control. An agent identity also records a human who is accountable for the agent, and it is often used outside your perimeter, where the agent signs up for apps and deals with people.

What is Know Your Agent (KYA)?

Know Your Agent is the payments industry’s term for verifying an AI agent before it transacts, modeled on Know Your Customer. In September 2026, Visa, Mastercard and Ant International began work on a shared KYA framework so agent verification doesn’t have to be repeated on every network.

Is there a standard for AI agent identity?

Not a single one as of October 2026. MCP standardizes authorization on OAuth 2.1, the IETF’s WIMSE and Web Bot Auth working groups have adopted agent-related drafts, and NIST has a project concept out. Vendors fill the gap with their own products in the meantime.

Can an AI agent have its own email address?

Yes. On CarlyEmail, an agent can create its own inbox with one API call, or you can paste Read https://docs.carlyemail.com/llms.txt and set yourself up with an email address. into any agent. Until the owner confirms a six-digit code, it can email only that owner.

Give your agent a real inbox

Your agent gets its own email address. People can email it, it answers in the same thread, and your personal inbox stays out of it. Start with 3 inboxes, no card needed.

Get started
See the prompt
Read https://docs.carlyemail.com/llms.txt and set yourself up with an email address.