Microsoft, AWS and Google now each ship a dedicated identity service for AI agents, and they solve different parts of the problem in different ways. Microsoft Entra Agent ID is a directory-centric model of blueprints, agent identities and sponsors; Amazon Bedrock AgentCore Identity is a workload identity plus token vault that brokers outbound OAuth and API keys; Google Cloud's agent identity gives each deployed agent a SPIFFE-based, certificate-bound principal and adds an auth manager for user delegation. Organisations running agents on more than one platform need a like-for-like view of credential type, lifetime, delegation, policy and audit before they can set one standard. This guide compares the three on those dimensions from each vendor's documentation, explains how to combine them, and lists the gaps none of them closes. It is for identity architects, cloud platform teams and security leads setting agent identity standards.
Facts below come from vendor documentation read on 27 October 2026. These services are evolving quickly and the pages do not all state preview or general availability status, so confirm status and limits before committing to a design.
Key takeaways
- Three different centres of gravity. Entra centres on directory governance, AgentCore on credential brokering for outbound calls, Google on attested, non-impersonable workload principals.
- All three avoid static agent secrets. Entra agent identities have no credentials of their own, AgentCore keeps third-party tokens in a vault, and Google issues 24-hour certificates and bound tokens.
- User delegation is the hardest part everywhere. Entra uses on-behalf-of exchanges, AgentCore binds tokens to the user's iss and sub, Google's auth manager runs three-legged OAuth.
- None gives you cross-cloud governance. Inventory, sponsorship and review across platforms remain your job.
- Pick a home for accountability, not a single vendor. Most multi-cloud estates will use each platform's native agent identity for its own resources and federate to one directory for ownership and policy.
What each service is
- Microsoft Entra Agent ID: identity objects in the Entra directory. An agent identity blueprint defines a kind of agent and holds credentials; agent identities are special service principals created from it, with an optional paired agent user account. Sponsors are mandatory. Conditional Access, ID Protection and entitlement management apply to agents. See the Microsoft Entra Agent ID Guide.
- Amazon Bedrock AgentCore Identity: AWS describes it as an identity and credential management service for agents and automated workloads. Agent identities are workload identities, created automatically by AgentCore Runtime and Gateway or manually with
CreateWorkloadIdentityfor self-hosted agents. A token vault stores OAuth tokens, OAuth client credentials and API keys, and credential providers handle outbound authentication. See the AWS Bedrock AgentCore Security Guide. - Google Cloud agent identity: Google gives each agent deployed on Agent Runtime (Gemini Enterprise Agent Platform), Gemini Enterprise or Cloud Run a cryptographic identity based on SPIFFE, usable directly as a principal in IAM allow and deny policies. An auth manager acts as credential vault and broker for API keys, OAuth client credentials and delegated end-user tokens. See the Google Vertex AI Security Guide.
Side-by-side comparison
| Dimension | Entra Agent ID | AgentCore Identity | Google Cloud agent identity |
|---|---|---|---|
| Identity object | Agent identity (special service principal) from a blueprint; optional agent user | Workload identity with agent attributes, in a workload identity directory | SPIFFE ID and IAM principal per deployed agent resource |
| Identifier format | Object ID equal to app ID; blueprintId links to template | arn:aws:bedrock-agentcore:region:account:workload-identity/directory/default/workload-identity/agent-name | principal://agents.global.org-ORG_ID.system.id.goog/resources/SERVICE/RESOURCE_PATH |
| Agent's own credential | None; blueprint obtains tokens via federated identity credentials | Workload access token obtained through IAM-controlled APIs | Auto-provisioned X.509 certificate, valid 24 hours, auto-renewed |
| Upstream credential | Blueprint: managed identity (preferred), federation, certificate or secret (not for production) | The caller's IAM credentials (for the token APIs); Runtime and Gateway handle this when they host the agent | Google-managed; developers cannot create long-lived keys for agent identities |
| Token binding | Not described on the pages read | Workload access token scoped to a user-agent pair | Access tokens bound to the agent's certificate; mTLS by default to Google APIs, DPoP beyond Agent Gateway |
| Impersonation of the agent | Blueprint impersonates its agent identities by design | Callers with the token API permission obtain tokens for the workload | Google states agent identities cannot be impersonated |
| User delegation | On-behalf-of flow: subject is the user, actor is the agent identity | GetWorkloadAccessTokenForJWT binds the user's iss and sub; 3LO credential providers for external services | Auth manager runs three-legged OAuth and supports revocation |
| Outbound to third parties | Entra-issued tokens to Entra-protected APIs; others via the app | Built-in providers for Google, GitHub, Slack, Salesforce and Atlassian, plus custom OAuth 2.0 and API keys | Auth providers for API keys, OAuth client credentials, 2LO, 3LO and OIDC ID tokens |
| Inbound authentication of callers | Agents validate Entra access tokens | Custom JWT authorizer: OIDC discovery URL, allowed audiences, clients, scopes and required claims | Not described on the page read; a default Context-Aware Access policy enforces mTLS and DPoP binding |
| Policy controls | Conditional Access for agents and agent users, custom security attributes, blocked high-privilege roles and permissions | IAM policies on workload identity ARNs and token APIs; scoping credential providers by workload identity | IAM allow and deny, Principal Access Boundary, VPC Service Controls, default Context-Aware Access |
| Ownership model | Owners, mandatory sponsors, managers; sponsor transfer to manager | Not a directory feature; tagging and IAM | Not described; IAM bindings per principal |
| Risk detection | ID Protection risky agents (offline detections) | Not described on the pages read | Not described on the page read |
| Audit | Sign-in logs (agentSignIn), audit logs with agentType, Graph activity logs | Operations logged; AWS advises CloudTrail auditing of the IAM principal to userId relationship | Cloud audit logs identify the agent, and both agent and user when acting for a user |
| Tenancy | Agent identities single-tenant; blueprints can be multitenant | Per account and Region | Trust domain per organisation, or per project without an organisation |
Credential type and lifetime
The three services all remove long-lived secrets from the agent itself, but each leaves a different credential that still needs protecting.
- Entra: the risk concentrates in the blueprint. A client secret on a blueprint is a key to every agent created from it, which is why Microsoft says secrets should not be used in production and prefers managed identities as the blueprint credential.
- AgentCore: the token vault holds third-party OAuth tokens and API keys, encrypted with AWS KMS using customer-managed or service-managed keys. The sensitive control is who may call the workload access token APIs, because a workload access token unlocks the vault entries for a user-agent pair. Workload access tokens are for AgentCore services only, not external services.
- Google: the agent's X.509 certificate is valid for 24 hours and tokens are bound to it, so a stolen access token alone should not be replayable. Long-lived third-party credentials, where needed, sit in the auth manager.
Token lifetimes for the issued access tokens were not stated on the pages read for any of the three; measure them in your tenant and record them in the standard. For the wider credential design question, see the Credential Vaulting for AI Agents Guide and the DPoP Guide.
Delegation and acting for users
Every platform supports an agent acting for a person, and every one makes a different trade-off between convenience and proof of who that person is.
| Platform | Mechanism | What proves the user | Main caution |
|---|---|---|---|
| Entra | Agent on-behalf-of flow; tokens with the user as subject and the agent identity as actor | The user's Entra token presented to the agent | Conditional Access for delegated calls targets the user, not the agent; ID Protection attributes OBO risk to the user |
| AgentCore (JWT path) | GetWorkloadAccessTokenForJWT; Runtime and Gateway call it automatically after inbound auth | A validated IdP JWT (signature, issuer, expiry) | Recommended for production |
| AgentCore (userId path) | GetWorkloadAccessTokenForUserId | An unverified caller-supplied string | AWS warns that an authenticated caller could impersonate another user; deny the action where not needed and derive userId from a trusted source |
| Auth manager three-legged OAuth; on Gemini Enterprise, credentials decrypted at Agent Gateway | The user's sign-in and consent at the provider | Logs show both agent and user; on Gemini Enterprise the agent never sees the raw credential |
AWS's own example deny policy for the userId path is worth adopting directly: a statement denying bedrock-agentcore:GetWorkloadAccessTokenForUserId on the workload identity directory for every principal that does not need it. When an agent calls another agent or tool, the question becomes how the chain is represented; see Delegation Chains and Attenuated Authority for AI Agents and the OAuth Token Exchange and Delegation Guide.
Policy, governance and audit
- Least privilege guardrails: Entra blocks the most privileged directory roles and Graph permissions for agent identities outright. Google's Principal Access Boundary limits which resources an agent can reach regardless of other grants, and VPC Service Controls can include the Agent Identity APIs in a perimeter. AgentCore relies on standard IAM policy on the workload identity ARNs and on scoping credential providers by workload identity.
- Lifecycle: Entra has sponsors, access packages with expiry and a 30-day soft delete. Google warns that deleting an agent does not remove its IAM bindings and that a redeployed agent gets a new principal, so roles must be granted again and stale bindings removed. AgentCore identities created by Runtime or Gateway are service-managed and cannot call the workload access token APIs directly; manually created identities need their own clean-up process.
- Audit: Entra tags agent activity with
agentTypeandblueprintIdbut Graph activity logs need a join. Google logs both agent and user identity for delegated actions. AgentCore logs operations, and AWS specifically recommends CloudTrail review of which IAM principal supplied which userId.
Detection techniques that apply on every platform: watch for new credentials or roles granted to agent identities (T1098.001 Additional Cloud Credentials, T1098.003 Additional Cloud Roles) and for stolen agent tokens used elsewhere (T1528 Steal Application Access Token, T1550.001 Application Access Token).
Choosing and combining them
For most organisations the right question is not which one to pick but which one owns each decision.
| Situation | Practical choice | Why |
|---|---|---|
| Agents mainly act inside Microsoft 365 | Entra Agent ID as primary; agent users only where a mailbox or user object is required | Conditional Access, sponsors and Graph permissions are native |
| Agents hosted on AgentCore calling SaaS on users' behalf | AgentCore Identity for outbound credentials; inbound JWT authorizer pointed at the corporate IdP | Vault and 3LO providers remove token handling from agent code |
| Agents on Google Cloud reaching Google APIs and MCP servers | Google agent identity with Principal Access Boundary | Attested, bound credentials with no keys to manage |
| Agent on AWS or Google that must call Microsoft Graph | Entra blueprint federated to the external workload's identity; Microsoft documents workload identity federation and the Auth SDK sidecar for third-party agents | Avoids a Graph client secret stored on another cloud |
| Agent on Azure calling AWS resources | AWS IAM federation from the Entra-issued token | Keeps one credential root; see the Workload Identity Federation Guide |
| Self-hosted or Kubernetes agents | SPIFFE-based workload identity, federated into whichever platform holds the resources | One attestation model across clouds; see the SPIFFE and SPIRE Guide |
A workable rollout:
- Inventory agents across platforms and record, per agent, its native identity, upstream credential, delegation mode and data reached.
- Set one cross-platform standard: no static secrets on agents, a named human sponsor per agent, expiry on every grant, user delegation only through validated tokens.
- Adopt each platform's native identity for agents hosted there, starting with the agents that hold the broadest data access.
- Federate across clouds rather than copying credentials; test by revoking the upstream identity and confirming the downstream access fails.
- Centralise logs into one SIEM with a common agent identifier field mapped from
blueprintId, the workload identity ARN and the SPIFFE ID. - Review quarterly against the standard and retire agents without an active sponsor.
Small versus large organisations: a small team on one cloud should simply use that cloud's agent identity and its defaults. A large, multi-cloud estate needs the cross-platform standard and inventory first, otherwise each platform team will build a different model. The AI Agent Identity Security Buyer's Guide covers what to look for in tooling that spans platforms.
Framework mapping
| Framework | Reference | Where the services help |
|---|---|---|
| NIST SP 800-53 Rev. 5 | IA-9 Service Identification and Authentication, IA-5 Authenticator Management | Credential-less or certificate-bound agent identities; vaulted third-party credentials |
| NIST SP 800-53 Rev. 5 | AC-6 Least Privilege, AC-3 Access Enforcement | Blocked roles (Entra), Principal Access Boundary (Google), scoped IAM on workload identities (AWS) |
| NIST SP 800-53 Rev. 5 | AC-2 Account Management, AU-6 Audit Record Review | Sponsors and lifecycle; agent-tagged audit logs |
| NIST CSF 2.0 | PR.AA-01, PR.AA-05, DE.CM-03 | Managing agent identities and their authorisations, and monitoring their use |
| CIS Controls v8.1 | Control 5 Account Management, Control 6 Access Control Management | Inventory and least privilege for agent accounts |
| ISO/IEC 27001:2022 Annex A | 5.16 Identity management, 5.17 Authentication information, 8.15 Logging | Agent identity lifecycle, credential handling and logs |
Common failure patterns
- Using the userId path in production: AgentCore's
GetWorkloadAccessTokenForUserIdtrusts the caller's string. Leaving the permission broadly granted lets any authorised caller fetch another user's vaulted tokens. - Secrets on Entra blueprints: a single secret compromises every agent of that kind.
- Stale Google IAM bindings: deleted agents leave bindings behind, and redeployed agents silently gain fresh grants while old principals remain in policy.
- Assuming policy follows the agent across clouds: Conditional Access does not evaluate AWS or Google calls, and Principal Access Boundary does not evaluate Graph calls. Each platform enforces only its own resources.
- Keys outside the model: on every platform, an agent that calls a service with an API key stored in code bypasses the identity service entirely. Entra notes Conditional Access does not apply to API keys; the Moltbook database exposure shows how quickly agent API keys leak at scale.
- No owner across platforms: only Entra has a sponsor concept. Agents on the other two platforms need ownership recorded elsewhere, or they will outlive their purpose.
Practitioner checklist
- Build one inventory of agents across Entra, AgentCore and Google Cloud with identity, credential, delegation mode and owner.
- Remove client secrets from Entra blueprints and long-lived keys from any agent runtime.
- Deny
GetWorkloadAccessTokenForUserIdwherever a validated JWT is available. - Configure the AgentCore inbound JWT authorizer with allowed audiences and clients, not discovery URL alone.
- Apply Principal Access Boundary to Google agent principals and remove bindings when agents are deleted or redeployed.
- Create Conditional Access policies for Entra blueprints and agent users, including a block for High agent risk.
- Federate cross-cloud access from the native agent identity instead of copying credentials.
- Normalise agent identifiers in the SIEM and alert on new credentials, roles and unusual token use for agents.
Standards and references
- Microsoft Learn: What are agent identities
- Microsoft Learn: Microsoft Entra Agent ID authentication protocols
- AWS: Amazon Bedrock AgentCore Identity
- AWS: Get workload access token
- AWS: Features of AgentCore Identity
- Google Cloud: Agent identity
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Agent Identity Standards Tracker · Microsoft Entra Agent ID Guide · AWS Bedrock AgentCore Security Guide · Agent Identity and Access Guide