What the platforms verifiably ship
Lesson 3 of 5 in Agent Identity, Auth, and Secrets.
Two hyperscalers have shipped agent identity as a first-class platform service, and their designs converge on the same primitives with different names. Learn the primitives; the names will change again.
What follows is deliberately narrow: only what vendor documentation stated when this module was checked, with the preview and status caveats intact. This is an educational module about the shape of these services, not vendor documentation — before you design against any line below, open the current docs.
| The primitive | Microsoft (Entra Agent ID + Foundry) | AWS (Amazon Bedrock AgentCore) | What to verify in the live docs |
|---|---|---|---|
The agent principal | An agent identity: documented as a special kind of service principal, with object ID, display name and an optional human sponsor. It holds no credentials of its own — an agent identity blueprint (a reusable template, with parent-child relationships) acquires tokens for it. | An agent identity implemented as a workload identity with specialized attributes, each with a distinct ARN in a central agent identity directory. | Whether the identity is created per agent or per deployment, and who is recorded as accountable owner. |
Automatic per-agent identity | Each hosted agent in Foundry Agent Service automatically receives a dedicated Entra identity; prompt agents also support Entra agent identity per Microsoft’s compare table. | Agent identities are registered in the directory; access to AWS resources from the agent goes through the AgentCore Runtime execution role (IAM). | Whether your deployment style gets an identity automatically or you must create one. |
Inbound auth (who may invoke the agent) | Entra tokens; agents published to Microsoft 365 and Teams get an authorization scheme set at publish time, with org-wide scope requiring Microsoft 365 admin approval. | Two mechanisms: IAM SigV4 for callers inside the AWS boundary, and OAuth JWT bearer tokens validated by an authorizer (IdP discovery URL plus allowed clients) configured at CreateAgentRuntime — Cognito, Okta, Entra ID and similar providers. | Which IdPs are supported in your region, and whether the authorizer is set at create time only. |
Delegation (on-behalf-of) | With a user token present, a hosted agent uses OAuth 2.0 On-Behalf-Of to call downstream services with delegated permissions; without one it authenticates as its own agent identity. Interactive agent tokens carry subject = user, actor = agent identity. | Validated user tokens are exchanged for workload access tokens ( | Whether the downstream resource server actually enforces the intersection of agent and user scopes, or trusts the token blindly. |
Credential storage | Foundry Toolbox centralizes credential injection, token refresh and policy enforcement via Entra ID and OAuth identity passthrough, so consuming agents do not manage per-tool credentials. | A token vault stores OAuth 2.0 access and refresh tokens, API keys and OAuth client secrets, encrypted with AWS KMS keys (customer-managed keys supported), with native integration to AWS Secrets Manager. User-specific credentials are documented as accessible only by the individual agent acting for that user. | Key ownership (platform-managed vs customer-managed) and who can read the vault from outside the agent path. |
Per-connection auth choices | MCP server/tool connections support: none, custom keys, OAuth2 (a Foundry-managed OAuth app or your own registration), user Entra token, project managed identity, and agentic identity — the agent’s own Entra identity. | AgentCore Gateway provides both ingress authentication (who may call the gateway) and egress authentication (credentials for backend targets); Gateway also gained IAM authorization for agent-to-tool MCP calls. | Which option each individual tool connection is actually using — this is where "we use OBO" quietly becomes "except those four tools". |
Inventory / registry | Entra Agent Registry, converging with Microsoft Agent 365 as the unified inventory, with Entra Agent ID providing identity and access management for discovered agents. Agent 365 is separately licensed. | AWS Agent Registry (GA August 2026): a governed catalog of MCP servers, tools, agents and skills, with hybrid search, approval workflows for publishing, IAM and OAuth (custom JWT) access control, a native MCP endpoint, Organizations auto-detection of Runtimes and Gateways, and CloudTrail audit trails. | Whether the registry is authoritative (nothing runs unless registered) or advisory (a nice list nobody enforces). |
Cross-platform reach | Entra Agent ID documentation describes working with non-Microsoft platforms — AWS Bedrock and n8n are named — via an Entra ID Auth SDK sidecar or workload identity federation. | AgentCore inbound OAuth integrates external IdPs including Microsoft Entra ID; agents hosted elsewhere can still ship telemetry to AgentCore Observability via the ADOT SDK. | Whether federation covers the delegation path or only the agent’s own authentication. |
Seven questions to ask any agent platform (including your own)
- Does each agent get its own principal automatically, or do I have to remember? Anything optional will be skipped under deadline.
- Can the agent act on behalf of a user with the actor still visible downstream? If the only option is forwarding the user’s token, you cannot have both delegation and attribution.
- Where do credentials live, and can the agent’s own code read them? The right answer is a vault plus runtime injection — the agent gets an authorized call, not a secret.
- What is the default credential lifetime, and is it audience-restricted? "Short-lived" is a claim; TTL and audience are the facts.
- Can I revoke one agent — or one user’s consent to one agent — without an outage? Test this before you need it.
- Does every tool call log the agent version, the acting principal, the subject, and the task id? If any field is missing, incident reconstruction becomes archaeology.
- Is the inventory authoritative? A registry that lists agents but cannot stop an unregistered one from running is documentation, not a control.
Why "the agent identity has no credentials of its own" is a feature, not a gap
Entra’s model is explicit: the agent identity is a subject you scope, audit and revoke, while token acquisition happens through the blueprint. Splitting the two means the thing you reference in policy and logs is not the thing an attacker could steal.
Generalize it: the identity is a name plus a permission set; the credential is a short-lived artefact issued against it. Any design where the identity is the credential — a long-lived key that means "I am the agent" — collapses that split, and every incident then starts with "we do not know whether the key leaked".
Both clouds now front tool access with a policy-enforcing broker. That matters for identity.
AWS routes tool access through AgentCore Gateway, which handles ingress and egress auth, and since July 2026 evaluates Bedrock Guardrails checks at the gateway layer — outside the agent’s code, where the agent cannot reason around them. Microsoft routes tools through a Toolbox with centralized credential injection, token refresh and policy enforcement behind a single managed MCP-compatible endpoint, with guardrail intervention points on tool call and tool response (preview for agents).
The identity lesson is the architectural one: put credentials and policy in the broker, not in the agent. When a new tool is added, it inherits enforcement instead of needing its own key and its own review.
What if I am not on either platform?
Nothing above requires a hyperscaler. The primitives are portable: a per-agent principal in your existing IdP; OAuth 2.0 token exchange for delegation; your existing secret manager as the vault with injection at the boundary rather than into the process; short TTLs with audience restriction; and a broker or gateway that all tool traffic passes through. The platforms bundle these; you can assemble them. What you cannot do is skip one and call the result agent identity.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.