Cloud Agent Identity Services Compared

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 CreateWorkloadIdentity for 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
Google	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 agentType and blueprintId but 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 GetWorkloadAccessTokenForUserId trusts 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 GetWorkloadAccessTokenForUserId wherever 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.

Cloud Agent Identity Services Compared (Entra, AgentCore, Google): Guide to Choosing and Combining Them