- Home
- AI agents
- Agent identity and access
- What is agent identity?
Govern and secure · Agent identity and access
What is agent identity?
Agent identity is a non-human identity for each AI agent: an identity object, a credential that rotates, an owner and a sponsor, the permissions it holds or borrows from a user, the policy evaluated when it asks for a token, and the log written under its name. It is what you allow, limit, audit and revoke.
In this guide: 83 pages
Key takeaways
- An agent identity is a workload identity with two things added: a human who answers for it, and rules for acting on behalf of a user. The IETF and the OpenID Foundation both describe it that way.
- It differs from a service account in sponsorship, agent-aware audit and lifecycle, which Microsoft says ordinary service principals lack.
- An agent proves itself to a tool with a short-lived token bound to that tool. MCP clients must name the server a token is for, and servers must refuse tokens issued for anyone else.
- The standards are young: RFC 8693 token exchange is from 2020, the MCP authorization specification is 2026-07-28, and the ID-JAG draft behind enterprise MCP access was at revision -06 on 31 Oct 2026.
How is an agent identity different from a service account or a user account?
An agent identity carries three things a service account lacks: an enforced human sponsor, audit records that name the agent, and a lifecycle that creates, disables and deletes it as a class. A user account used by an agent is worse, because it drags the user's rights and the user's policies into every call.
Three ways to run an agent, compared.
| Question | Human user account | Service account (service principal) | Agent identity |
|---|---|---|---|
| Who it represents | A person | An application or job | One agent, acting for a user or as itself |
| Who answers for it | The person | Often nobody, after the creator moves on | A named owner and a business sponsor; Entra transfers sponsorship when someone leaves |
| Credentials | Password and MFA | Client secret or certificate, often long-lived | Managed identity or federated credential (Entra); KMS-held keys and a token vault (AgentCore); 24-hour certificates (Google) |
| Delegation | Acts as itself | App-only, or standard OAuth on-behalf-of as an ordinary application, with no sponsor or blueprint lifecycle | Agent on-behalf-of flow with the acting agent recorded and permissions pre-authorized on the blueprint; autonomous flow when no user is present |
| Policy | User Conditional Access | Limited; API keys bypass it | Conditional Access for agents by identity, blueprint or attribute; AgentCore Policy; Google Agent Gateway |
| Audit | Sign-ins as the person | One log for every agent that shares it | Sign-in and audit logs filtered by agent type; risk detections per agent |
| Lifecycle | Joiner, mover, leaver | Manual, often forgotten | Blueprint cascade and 30-day soft delete (Entra); delete the workload identity (AgentCore); remove IAM bindings by hand (Google) |
Microsoft's own words: traditional service principals lack enforced sponsorship, agent-aware audit and blueprint lifecycle, and reusing regular user accounts for agents breaks Conditional Access, ID Protection and governance (Entra Agent ID key concepts, ms.date 3 Apr 2026).
What does an agent identity consist of?
Six parts, each answering one question: an identity object (who it is), an owner and sponsor (who answers for it), a credential (how it proves itself), permissions (what it may do), policy (what the company says), and logs (what it did).
- Identity object. In Microsoft Entra, an agent identity is created from an agent identity blueprint; the blueprint holds the credentials and can only create or delete agent identities, a blueprint principal represents it in each tenant, and an agent identity has no credentials of its own. On AWS, a workload identity in the AgentCore Identity directory with its own ARN. On Google Cloud, a SPIFFE ID of the form spiffe://TRUST_DOMAIN/resources/SERVICE/RESOURCE_PATH with an IAM principal.
- Owner and sponsor. Entra separates owners (technical) from sponsors (business accountability) and managers, with lifecycle workflow templates that notify cosponsors and transfer sponsorship when a sponsor changes role or leaves. AWS Agent Registry records carry publisher and ownership fields, and Gemini Enterprise holds an owner per agent.
- Credential. Microsoft calls managed identity the preferred credential for a blueprint and says client secrets should not be used in production; Foundry provisions a federated identity credential per agent so no secret exists. AWS added Private Key JWT with the key in KMS (July 2026). Google issues a 24-hour X.509 certificate per agent and renews it automatically.
- Permissions. Delegated permissions are pre-authorized on the blueprint as inheritable permissions, because agents cannot run interactive consent flows; autonomous permissions are granted to the identity itself. New Foundry agent identities start with zero permissions. On AWS, IAM roles and Gateway scopes; on Google Cloud, IAM roles on the principal.
- Policy. Conditional Access for agents evaluates the identity, its blueprint, custom security attributes and risk before a token is issued, and ships templates for high-risk, autonomous and on-behalf-of agents. AgentCore Gateway and Policy decide at the tool call; Google Agent Gateway does the same with IAM Unified Access Policies (generally available 31 Aug 2026).
- Logs. Entra sign-in and audit logs filter by agent type, and ID Protection for agents detects sign-in spikes, unfamiliar resource access and suspicious credential use (detections are offline, and in on-behalf-of flows risk is attributed to the user). AgentCore writes Gateway authentication events to CloudTrail, where AWS recommends pairwise subject identifiers to keep personal data out of the log.
How does an agent prove who it is to a tool?
With a short-lived access token issued by the identity provider for that one tool, after policy has been evaluated, and never by forwarding a token it received from someone else.
The flow has four steps. The agent authenticates with its credential (managed identity, federated credential, KMS-held key or certificate) and, if it is acting for a user, presents the user's token as well. The identity provider evaluates policy and issues a token whose audience is the tool. The agent sends the token; the tool validates that the token was issued for it and reads the claims, including which agent is acting and, in a delegated call, for which user. The tool enforces its own authorization from those claims.
The MCP authorization specification (2026-07-28) makes the audience rule explicit: clients must send the RFC 8707 resource parameter naming the server, servers must validate that a token was issued for them, and servers must not accept or pass through other tokens. AWS says the same about its Gateway, where JWT passthrough is labelled as not for production and on-behalf-of exchange is the recommended pattern.
For many MCP servers behind one corporate identity provider, the Enterprise-Managed Authorization extension (stable, keyed to 2026-07-28) adds a step: the client obtains an identity assertion from the corporate provider and exchanges it at the MCP server's authorization server, so IT grants and revokes access centrally. Okta markets this as Cross App Access, and Ping Identity's PingFederate 13.1 issues and accepts the assertions; Microsoft Entra was not listed as an issuer on the MCP implementation table on 2 Nov 2026.
Is agent identity a standard yet?
Partly. The building blocks are standards; the agent-specific layer is a set of drafts and one stable MCP extension, and the vendor products run ahead of them.
Standards and specifications behind agent identity, with status on 2 Nov 2026.
| Specification | What it covers | Status on 2 Nov 2026 |
|---|---|---|
| OAuth 2.0 Token Exchange, RFC 8693 | Impersonation versus delegation; the act claim that records which agent acts for which subject | Proposed Standard, January 2020 |
| MCP authorization | OAuth 2.1 profile for MCP servers: resource indicators (RFC 8707), protected resource metadata (RFC 9728), issuer validation, client ID metadata documents | Specification 2026-07-28; Dynamic Client Registration deprecated |
| MCP Enterprise-Managed Authorization | The corporate identity provider issues an identity assertion that the MCP server's authorization server exchanges for a token | Stable extension, keyed to 2026-07-28 |
| ID-JAG (Identity Assertion JWT Authorization Grant) | The IETF draft the extension is built on | Internet-Draft -06, 31 Oct 2026; not an RFC; implementations target different revisions |
| IETF WIMSE AIMS | Maps agents onto workload identity, SPIFFE, OAuth and shared signals; defines no new protocol | Working group draft -01, 2 Nov 2026, Informational |
| SPIFFE, with SPIRE as its implementation | Short-lived workload identity documents, attestation and federation | Open standard with a reference implementation; Google Agent Identity is SPIFFE-based |
| OpenID Foundation whitepaper | Why today's OAuth strains under recursive delegation and autonomous agents | Published 7 Oct 2025 |
The practical consequence: build on token exchange and audience binding today, expect the enterprise MCP extension to move with the draft, and keep API-key integrations in a vault with an expiry until the tool supports OAuth.
How do Microsoft, AWS and Google implement it?
The identity object, credential and policy point on each cloud, as seen 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Identity object | Entra agent identity from a blueprint (GA, Learn 1 May 2026) | AgentCore workload identity with an ARN (GA 13 Oct 2025) | SPIFFE ID with an IAM principal (stage inconsistent; API preview 18 Jun 2026) |
| Credential | Managed identity or federated credential on the blueprint | KMS token vault; Private Key JWT (Jul 2026) | 24-hour X.509 certificate, auto-renewed |
| Policy point | Conditional Access for agents at token issuance | Gateway inbound authorization and AgentCore Policy at the tool call | Agent Gateway with IAM Unified Access Policies (GA 31 Aug 2026) |
| Created automatically by | Copilot Studio (since Jul 2026) and new Foundry agents | AgentCore Runtime deployments, one workload identity per agent | Agent Runtime, Gemini Enterprise and Cloud Run deployments |
Google's documentation pages show no launch stage for Agent Identity; the platform release notes list it as generally available at launch and the API as preview on 18 Jun 2026.
Frequently asked questions
Is an agent identity the same as a service principal?
No. In Entra an agent identity is a distinct object created from a blueprint, with a sponsor, agent-aware audit and a cascade lifecycle that a service principal lacks. On AWS and Google the agent is a workload identity with delegation and ownership added. The job is the same, authenticating software, but the governance around it is different.
Does an agent identity have a password or secret?
It should not. Entra uses a managed identity or a federated identity credential on the blueprint and warns against client secrets in production; AgentCore holds keys in KMS and tokens in a vault; Google issues a 24-hour certificate it renews itself. Secrets in agent code are the thing agent identity exists to remove.
How does an agent act on behalf of a user without the user's password?
Through token exchange. The user signs in to the client, the client passes the user's token to the agent, and the agent exchanges it with the identity provider for a new token scoped to the downstream tool, with the agent recorded as the actor. The user's rights are the ceiling, and the user's password is never seen.
Which standard should we build agent identity on?
Token exchange with audience-bound tokens: RFC 8693 where the platform supports it (AgentCore does, in RFC 8693 and RFC 7523 modes), Entra's agent on-behalf-of flow on Microsoft, plus the MCP authorization specification (2026-07-28) for tool servers. Treat the Enterprise-Managed Authorization extension and the ID-JAG draft as useful but moving, and SPIFFE as the model for the identity document itself.
More in Agent identity and access
Sources
Each source was read on 2 November 2026. The date shown is the date on the page, or the page’s ms.date for Microsoft Learn; an undated page shows the date it was read.
- Microsoft Entra Agent ID key concepts
- Agent identity blueprints
- Agent OAuth flows: on-behalf-of flow
- What's new in Microsoft Entra Agent ID
- Conditional Access for agents in Microsoft Entra
- ID Protection for agents (risky agents)
- Agent identity in Microsoft Foundry
- Agent identity deletion
- AgentCore Identity key features and benefits
- On-behalf-of token exchange (AgentCore Identity)
- AgentCore Gateway inbound authorization
- AgentCore release notes
- Securing AI agents with Amazon Bedrock AgentCore Identity
- Agent Identity overview
- Agent identity for Agent Runtime
- Gemini Enterprise Agent Platform release notes
- MCP authorization (specification 2026-07-28)
- MCP Enterprise-Managed Authorization extension
- Identity Assertion JWT Authorization Grant (ID-JAG), draft -06
- AI Identity Management System (WIMSE AIMS), draft -01
- OAuth 2.0 Token Exchange, RFC 8693
- New whitepaper tackles AI agent identity challenges
- SPIFFE overview
- Cross App Access (XAA)
Planning an AI program?
Talk to the team that builds it and runs it after launch.
- Built to SOC 2, HIPAA and GDPR standards
- EU AI Act-aligned delivery
- Microsoft Solutions Partner