Govern and secure · Topic 09 of 14
AI agent identity and access: should every agent have its own identity?
Agent identity and access is the practice of giving each AI agent its own governed non-human identity, deciding whether it acts for a user (on behalf of) or as itself (autonomous), and issuing it short-lived tokens scoped to the tools and data it needs. Each agent then has an owner, a rotating credential and a switch that revokes it.
In this guide: 83 pages
Key takeaways
- Yes, every agent needs its own identity. Microsoft says reusing user accounts or shared service principals for agents breaks Conditional Access, ID Protection and governance, and an auditor cannot tell which agent did what under a shared account.
- Decide the access pattern per call: on behalf of a user, so the agent can never exceed the user's rights, or autonomous with its own grants and a tighter review.
- All three clouds ship it: Microsoft Entra Agent ID (generally available, Microsoft Learn 1 May 2026), Amazon Bedrock AgentCore Identity (generally available 13 Oct 2025) and Google Agent Identity (launch stage shown inconsistently; the API was marked preview on 18 Jun 2026).
- The token rules are now written down: MCP clients must say which server a token is for, servers must refuse tokens issued for someone else, and nobody forwards a user's token downstream.
- An identity is useful once it has an owner, a sponsor, a rotating credential and a tested disable switch. A static API key bypasses the identity policy on that path.
Why do AI agents need their own identity?
Because every control that matters, allowing, limiting, logging and revoking, attaches to an identity, and a shared account cannot carry any of them per agent. An agent running as a human user or a shared service account inherits rights nobody reviewed and leaves an audit trail nobody can read.
Microsoft's documentation is blunt about it: 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). The IETF's WIMSE working group treats an agent as a workload identity with delegation rules on top (AIMS draft -01, 2 Nov 2026), and the OpenID Foundation's whitepaper of 7 Oct 2025 argues that today's OAuth strains under recursive delegation and highly autonomous agents, so agents should be first-class IAM identities.
The audit argument is the one that lands with risk teams. A shared service account used by twelve agents produces one sign-in log, one set of permissions and one off switch. When an auditor asks which agent read the payroll table, the answer is "one of twelve", and when one agent misbehaves, the switch stops all twelve. With an identity per agent, the log names the agent, Conditional Access can block that agent alone, and disabling its identity stops token issuance without touching anything else. The second reason is blast radius: an agent with a user's full rights can do anything the user can, from a prompt it read in an email, while an agent with a scoped token can do the three things it was granted.
How does agent identity and access work?
You set up ten things, in roughly this order: an identity object per agent, an access pattern per call, token exchange instead of token forwarding, no static secrets, a vault for third-party tokens, scoped and audience-bound tokens, policy at issuance, an owner and a sponsor, monitoring of agent sign-ins, and central control of MCP access.
- Give every agent its own identity object. In Microsoft Entra an agent identity is created from an agent identity blueprint, which holds the credentials; disabling the blueprint disables every agent made from it. On AWS each agent is a workload identity with its own ARN in the AgentCore Identity directory. On Google Cloud each agent gets a SPIFFE-based principal (SPIFFE is the open standard for workload identities).
- Pick the access pattern per call. Delegated, or on behalf of: the agent exchanges the user's token for a new token scoped to the downstream resource, so it can never exceed the user's rights. Autonomous, or app-only: the agent uses its own identity and grants. Agent-as-user, Microsoft only: an optional user account linked to the agent, with a mailbox and licences, for systems that require a user object.
- Exchange tokens; never forward them. OAuth 2.0 Token Exchange (RFC 8693) separates impersonation from delegation and records which agent acts for which subject. Entra's agent on-behalf-of flow uses the JWT-bearer grant with requested_token_use=on_behalf_of; agents cannot run interactive sign-in flows, so delegated permissions are pre-authorized on the blueprint. AgentCore Identity added on-behalf-of token exchange in April 2026, with a preset for Microsoft's flow.
- Remove static secrets. Microsoft calls managed identity the preferred credential for a blueprint and warns against client secrets in production; Foundry provisions a federated identity credential per agent so no secret exists. AWS added Private Key JWT client authentication with the key in KMS (July 2026). Google issues each agent a 24-hour X.509 certificate and binds access tokens to it.
- Keep third-party tokens in a vault keyed to agent plus user. The AgentCore Identity token vault stores OAuth tokens, client credentials and API keys encrypted with KMS and releases them only to the right agent with proof of its workload identity. Auth0 Token Vault does the same for connected accounts such as Google or Slack.
- Scope and audience-bind every token. Under the MCP authorization specification (2026-07-28), clients must send the RFC 8707 resource parameter, servers must validate that a token was issued for them, and servers must not accept or pass through tokens issued for another audience. Ask for minimal scopes and step up on an insufficient_scope challenge.
- Apply policy when the token is issued, and again at the tool call. Conditional Access for agents evaluates the agent identity, its blueprint, custom security attributes and agent risk before Entra issues a token. On AWS, AgentCore Gateway enforces JWT or IAM inbound authorization and AgentCore Policy decides which tools an agent may call. On Google Cloud, Agent Gateway sits in front of tool calls.
- Assign an owner, a sponsor and a lifecycle. Entra separates owners (technical) from sponsors (business accountability) and ships lifecycle workflows that transfer sponsorship when a sponsor leaves, "to prevent orphaned agents". On Google Cloud, deleting an agent leaves inactive IAM bindings you must remove.
- Monitor agent sign-ins and risk. Entra sign-in and audit logs filter by agent type, and ID Protection for agents flags sign-in spikes, unfamiliar resource access and suspicious credential use, which a Conditional Access policy can turn into a block.
- Let the identity provider decide MCP access. The MCP Enterprise-Managed Authorization extension (stable, keyed to 2026-07-28) has the client obtain an identity assertion from the corporate identity provider and exchange it at the MCP server's authorization server, so IT grants and revokes access centrally. The underlying IETF draft, ID-JAG, was at revision -06 on 31 Oct 2026 and is not an RFC.
On-behalf-of vs autonomous access: which should an agent use?
Use on-behalf-of whenever a signed-in person is present and the agent should see only what that person can see; use autonomous access for scheduled or event-driven work with no user, and give it narrower grants and a tighter review. Many agents use both, one per call.
The three access patterns, as Microsoft Entra names them; AWS and Google implement the first two.
| Question | On behalf of (delegated) | Autonomous (app-only) | Agent-as-user (Microsoft only) |
|---|---|---|---|
| Who the token represents | The user, with the agent identified as the caller | The agent identity | The agent's own user account |
| Ceiling on rights | The user's rights, narrowed by scope | Whatever the agent was granted; no user ceiling | Whatever the account and its licences allow |
| Typical use | Reading a user's mail or files; acting in a chat | Nightly reconciliation; reacting to events; calling a backend users cannot reach | A digital worker that needs a mailbox, chat and group membership |
| Conditional Access target | Policies on the user; an agent-identity policy does not cover these calls | The agent identity or its blueprint | The agent's user account; policies scoped to Users do not apply |
| Where risk is attributed | To the user (ID Protection) | To the agent | To the agent's user account |
| AWS and Google equivalent | AgentCore user binding and on-behalf-of token exchange; Google auth manager for user-delegated access | AgentCore workload identity with client credentials; Google SPIFFE principal with IAM roles | No direct equivalent |
Microsoft's own warning is worth repeating: an agent can use more than one pattern, so write a separate policy for each token subject, because a policy on an agent identity does not apply to the agent's user account and a policy on users does not apply to agent users (Conditional Access for agents, ms.date 31 Jul 2026).
How do Microsoft, AWS and Google do agent identity?
All three give each agent an identity of its own, a credential that does not live in code, and a policy point in front of tool calls; they differ in maturity, licensing and how clearly they state launch stage. The table gives the status each page showed on 2 Nov 2026.
Agent identity products as of 2 Nov 2026.
| Product | Identity model | Credentials and delegation | Status and licensing as seen 2 Nov 2026 |
|---|---|---|---|
| Microsoft Entra Agent ID | Agent identity blueprint (holds credentials, creates identities), blueprint principal per tenant, agent identity, optional agent user account; owners, sponsors and managers | Managed identity or federated credential on the blueprint; agent OBO flow with inheritable delegated permissions; autonomous flow; Conditional Access and ID Protection for agents | Generally available (Microsoft Learn, ms.date 1 May 2026); creation wizard still preview. Available to all Entra customers; Conditional Access for agents needs Microsoft 365 E7, or Agent 365 with at least Entra P1 or Microsoft 365 E3 (Microsoft Learn, 31 Jul 2026); ID Protection page says an Agent 365 licence will be required. Agent 365 lists at USD 15 per user per month or is included in Microsoft 365 E7 (Microsoft Security Blog, 1 May 2026) |
| Amazon Bedrock AgentCore Identity | Workload identity directory with a per-agent ARN; inbound JWT or IAM authorizers at the Gateway; outbound credential providers | KMS-encrypted token vault; built-in providers for Google, GitHub, Slack, Salesforce and Atlassian; user binding of a JWT to an agent token; OBO token exchange since April 2026; Private Key JWT since July 2026; Consent Portal since September 2026 | Generally available since 13 Oct 2025 (preview from July 2025); AgentCore Policy generally available 3 Mar 2026 |
| Google Agent Identity (Gemini Enterprise Agent Platform) | SPIFFE ID per agent with an IAM principal; covers Agent Runtime, Gemini Enterprise and Cloud Run | 24-hour X.509 certificate per agent, renewed automatically; access tokens bound to it; auth manager for third-party credentials and user-delegated access | No launch stage on the documentation pages; the release notes list Agent Identity as generally available at the April 2026 launch and the Agent Identity API as preview on 18 Jun 2026. Treat the API as preview |
| Independent vendors | Okta Cross App Access (built on ID-JAG); Ping Identity PingFederate 13.1 issues and accepts ID-JAGs | Auth0 Token Vault; Palo Alto Networks Idira (formerly CyberArk Secure AI Agents) and SailPoint Agentic Fabric (formerly Agent Identity Security) discover agents and assign owners | Per the MCP project's implementation table, self-reported by vendors; GA dates for Okta and Auth0 agent products not verified on 2 Nov 2026 |
Two notes on Microsoft. Copilot Studio has created an Entra agent identity for every new agent since July 2026 with no environment-level opt-out, and new Foundry agents get their own blueprint and identity with zero permissions to start, while legacy Foundry agents still share a project identity; delegated access for Foundry tools was preview on 28 Oct 2026.
How do Microsoft, AWS and Google implement it?
The same capability on each cloud, with the status the vendor pages showed on 2 Nov 2026.
Capability, Microsoft, AWS, Google
| Capability | Microsoft | AWS | |
|---|---|---|---|
| Identity object | Entra agent identity from a blueprint (GA, Learn 1 May 2026) | AgentCore Identity workload identity with an ARN (GA 13 Oct 2025) | SPIFFE-based Agent Identity (stage inconsistent; API preview 18 Jun 2026) |
| Credential | Managed identity or federated credential on the blueprint; no client secrets in production | KMS-encrypted token vault; Private Key JWT with KMS (Jul 2026) | 24-hour X.509 certificate, auto-renewed; tokens bound to it |
| On behalf of a user | Agent OBO flow (JWT-bearer, requested_token_use=on_behalf_of); inheritable permissions | User binding of the inbound JWT; OBO token exchange (Apr 2026) | Auth manager brokers user-delegated access |
| Policy at issuance or tool call | Conditional Access for agents (GA; licensed plans rolled out Jul to Aug 2026) | Gateway inbound JWT or IAM; AgentCore Policy (GA 3 Mar 2026) | Agent Gateway with IAM Unified Access Policies (GA 31 Aug 2026) |
| Owner and lifecycle | Owners, sponsors, managers; sponsor lifecycle workflows; disable; 30-day soft delete | Publisher and ownership fields in AWS Agent Registry; delete the workload identity | Owner in Gemini Enterprise; deleted agents leave IAM bindings to clean up |
| MCP access from the identity provider | Entra not listed as an ID-JAG issuer on the MCP implementation table | Gateway authorization-code flow for MCP targets (GA Apr 2026) | Not verified on 2 Nov 2026 |
This page quotes the Agent 365 standalone price only, as Microsoft published it; Microsoft notes that pricing varies by agreement.
When is an identity not enough, and what goes wrong?
A separate identity does nothing if the token it gets is forwarded, if an API key bypasses the policy, or if nobody owns it. These are the failures we see in reviews, each with the vendor page that documents it.
Shared or human identities
An agent running as a person or a shared service principal makes audit, Conditional Access and lifecycle unreliable; Microsoft says outright that it breaks Zero Trust enforcement. The fix is one identity per agent, which Copilot Studio and Foundry now create by default.
Token passthrough and the confused deputy
Forwarding a user's token to a downstream tool lets any hop replay it against any resource the token was good for. The MCP specification forbids servers from accepting or transiting tokens not issued for them, and AWS labels Gateway JWT passthrough as not for production.
API keys that bypass policy
Conditional Access applies only when Entra issues the token. An agent that authenticates to a tool with an API key skips that pipeline, so no Conditional Access policy applies to the call. Keep keys in the vault, prefer OAuth, and treat a key as an exception with an expiry date.
Policy targeting gaps
In Entra, a policy scoped to Users does not apply to agent user accounts, a policy on an agent identity does not cover its user account, and group-based scoping of agent users is unsupported. In on-behalf-of flows ID Protection attributes risk to the user, so an agent-level risk policy misses delegated misuse.
Blueprint blast radius and open gateways
Permissions granted to a blueprint flow to every agent identity created from it, so a compromised blueprint credential affects the whole class; keep blueprints narrow. AgentCore Gateway inbound modes NONE and AUTHENTICATE_ONLY forward any caller unless a policy engine, an interceptor or the target enforces authorization.
Orphaned grants and spec churn
Deleting a Google agent leaves inactive IAM bindings, a redeployed agent gets a new principal, and Foundry's move to per-agent identities does not carry role assignments across. Meanwhile MCP deprecated Dynamic Client Registration in 2026-07-28, and ID-JAG implementations target different draft revisions.
What should you set up?
The controls that make an agent identity real, in the order we install them.
- One identity per agent, created from a narrow blueprint (Entra), a workload identity (AgentCore) or an agent principal (Google Cloud), with no human accounts and no shared service accounts in the agent fleet.
- A named owner and a business sponsor per identity, with a lifecycle workflow that reassigns sponsorship when someone leaves.
- The access pattern written down per tool call: on behalf of the user by default, autonomous only for the calls that need it, and a separate policy for each token subject.
- Credentials nobody can copy: managed identity or federated credential on Azure, KMS-held keys and the token vault on AWS, auto-renewed certificates on Google Cloud; API keys only in the vault, with an expiry.
- Token hygiene enforced at the gateway: resource-bound requests, audience validation, no passthrough, minimal scopes with step-up.
- Policy in front of tokens and tools: the Conditional Access templates for high-risk, autonomous and on-behalf-of agents; AgentCore Gateway authorization with AgentCore Policy; Google Agent Gateway policies.
- A tested disable switch per platform (disable the Entra identity or blueprint; revoke the AgentCore workload identity and vault entries; remove Google IAM bindings) and sign-in logs filtered by agent type on a weekly review.
Enterprise example · Worked example · illustrative
A regional bank runs a card-dispute agent on two access patterns
Illustrative scenario. A regional bank with 4,000 staff, a Microsoft 365 and Azure tenant, a core banking system behind an API gateway, and a card-dispute process that handles about 900 cases a week.
The first version ran under a shared service principal that three earlier bots also used, with Graph and core-banking rights accumulated over four years. Internal audit asked which agent had read a customer's statement on a given day and got the answer "one of four". That finding started the identity work.
The agent now has an Entra agent identity created from its own blueprint, with a managed identity as the credential and no client secret anywhere. When a dispute analyst works a case, the agent exchanges the analyst's token through the on-behalf-of flow and reads the statement with the analyst's rights, so an analyst who cannot see a restricted account cannot see it through the agent either. Overnight, a second step runs autonomously under the agent's own identity to pull settled transactions from the card network, with a grant to that one API and nothing else.
Conditional Access applies two templates: block high-risk agent identities, and allow the autonomous flow only from the bank's Azure network. The provisional-credit tool, which moves money, requires approval and is callable only in the delegated flow, so no autonomous run can credit an account. The card network's API key lives in a vault entry keyed to the agent, with a 90-day expiry the owner must renew.
Six months in, the sign-in log answers the auditor's question in one filter: this agent, this day, this resource. The one incident was a sign-in spike from a misconfigured retry loop, flagged by ID Protection and blocked by the high-risk template within the hour, without touching the three older bots, which had by then been given identities of their own.
- Owner
- Disputes operations manager as owner, head of cards as sponsor; sponsorship transfer workflow enabled
- Identity
- Entra agent identity from a dedicated blueprint; managed identity as the blueprint credential; no client secrets
- Access pattern
- On behalf of the analyst for case work; autonomous for the overnight settlement pull, scoped to one API
- Credentials
- Card network API key in a vault entry keyed to the agent, with a 90-day expiry
- Policy
- Conditional Access templates: block high-risk agent identities; autonomous flow allowed only from the bank network
- Risk tier
- Tier 3 because the provisional-credit tool moves money; the tool is callable only in the delegated flow
- Approval
- Provisional credit marked as requiring approval; analyst approves below a limit, supervisor above it
- Monitoring
- Entra sign-in logs filtered by agent type on a weekly review; ID Protection detections routed to the owner
- Retirement
- Disable the identity, revoke the vault entry, remove the API grant, archive the sign-in and approval logs; 30-day soft delete before the identity is purged
How do you start?
- Inventory every agent and the account it runs under; the shared service principals and human accounts are the backlog.
- Create one narrow blueprint per workload type on Microsoft, a workload identity per agent on AWS, or an agent principal on Google Cloud, with a managed credential and zero permissions to start.
- Move the highest-risk agent first: delegated flow for user-facing calls, autonomous only where no user exists, one policy per token subject.
- Put the gateway in front of every tool call, turn off passthrough, and move API keys into the vault with an expiry.
- Apply the three Conditional Access templates or their AWS and Google equivalents, then test the disable switch on a throwaway agent and write down what it leaves running.
- Add owner, sponsor and review date to each registry record, and re-check vendor statuses after Microsoft Ignite and AWS re:Invent in late 2026.
Frequently asked questions
Should AI agents have their own identity?
Yes. Microsoft's documentation says reusing user accounts or shared service principals for agents breaks Conditional Access, ID Protection and governance, and the IETF and the OpenID Foundation both model agents as first-class identities. An identity per agent is what lets you allow, limit, log and revoke one agent without touching the rest.
What is Microsoft Entra Agent ID?
Microsoft's identity service for AI agents, generally available per Microsoft Learn (1 May 2026). It adds agent identity blueprints, agent identities, optional agent user accounts, owners and sponsors, an agent on-behalf-of flow, and Conditional Access and ID Protection for agents. Copilot Studio creates one for every new agent, and Foundry provisions one per new agent.
How is Entra Agent ID licensed?
Microsoft Learn says Agent ID is available for all Microsoft Entra customers, with the extended security features needing Microsoft Agent 365. Conditional Access for agents needs Microsoft 365 E7, or Agent 365 with at least Entra P1 or Microsoft 365 E3 (Microsoft Learn, 31 Jul 2026), and the ID Protection page says an Agent 365 licence will be required. Agent 365 lists at USD 15 per user per month or is included in Microsoft 365 E7 (Microsoft Security Blog, 1 May 2026).
What is the difference between Entra Agent ID and Microsoft Agent 365?
Agent ID is the identity layer: who the agent is, how it authenticates, what it may access. The control plane that observes, governs and secures agents is Agent 365, which includes the registry in the Microsoft 365 admin center that the Entra agent registry converged into in April 2026. It went generally available on 1 May 2026 and carries the Conditional Access and ID Protection plans for agents.
Can an agent use an API key instead?
It can, and that is the problem. An API key bypasses Entra token issuance, so no Conditional Access policy applies, and a key in code is a secret waiting to leak. Prefer OAuth with token exchange; where a tool only takes keys, keep the key in the identity vault, bind it to the agent, and give it an expiry.
Does Google Cloud have agent identity?
Yes, a SPIFFE-based Agent Identity for Agent Runtime, Gemini Enterprise and Cloud Run, with a 24-hour certificate per agent and an auth manager for third-party credentials. Its launch stage was shown inconsistently on 2 Nov 2026: generally available in the platform launch notes, preview for the Agent Identity API on 18 Jun 2026. Treat the API as preview.
In this topic
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
- What's new in Microsoft Entra Agent ID
- Agent identity blueprints
- Agent OAuth flows: on-behalf-of flow
- Conditional Access for agents in Microsoft Entra
- ID Protection for agents (risky agents)
- Disable agent identities
- Agent identity deletion
- Agent identity in Microsoft Foundry
- What's new in Copilot Studio
- Microsoft Agent 365 now generally available
- Message Center MC1395007: Conditional Access and ID Protection for agents service plans (mirror)
- Amazon Bedrock AgentCore now generally available
- 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
- Cross App Access (XAA)
- Token Vault
- Idira Secure AI Agents
- Agent Identity Security, now SailPoint Agentic Fabric
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