There is a quiet assumption baked into most identity conversations, and it usually goes unstated because everyone in the room already believes it: Microsoft identity is for Microsoft resources, and you run it on Microsoft infrastructure. Both halves feel so obvious that nobody bothers to test them.
So I tested them. I built a proof-of-concept where an AI agent runs entirely on AWS, holds its own Microsoft Entra Agent ID, and uses that single identity to authorize calls to resources on both sides of the cloud boundary: a Microsoft service and an AWS Lambda. The agent never touches Azure compute. The Lambda never sees an AWS credential on the call. And nothing about it required a special bridge, because the bridge already exists and it is called OAuth.
The sample is astaykov/agentid-agentcore. This is the walkthrough of why it works, written for the architect whose first reaction to "Microsoft Entra in my AWS stack" is a raised eyebrow.
The shape of it, stated plainly
A browser single-page app signs the user in with MSAL.js and hands the resulting access token to an agent. The agent is hosted on AWS Bedrock AgentCore Managed Runtime, a fully managed runtime for agents. Inside that runtime, the agent acts on behalf of the signed-in user against two downstream resources:
- an AWS Lambda, fronted by an API Gateway HTTP API (the PoC calls it the Echo API), and
- the Microsoft MCP Server for Enterprise, the Microsoft-hosted tool surface over Microsoft Graph.
User
↓ sign-in (MSAL.js)
Browser SPA
↓ Entra access token [Bearer, header-only]
AgentCore Managed Runtime ── hosted on AWS, holds an Entra Agent ID
├─→ AWS Lambda (API Gateway HTTP API, native JWT authorizer)
└─→ Microsoft MCP server
Read that topology again and notice what is not in it. There is no Azure virtual machine, no Azure Container App, no Azure Function. The compute is 100% AWS. The identity is 100% Microsoft Entra. Those two facts are usually assumed to travel together. They do not.
The AWS resource is the whole point
It would be an unremarkable demo if the agent only called Microsoft services. Of course a Microsoft identity opens Microsoft doors. The claim that actually needs proving is the other one: that a Microsoft Entra-issued token can open an AWS door.
So look closely at the Echo API. It is an AWS API Gateway v2 HTTP API in front of a Lambda function. Nothing about it is Microsoft. And its access control is a native API Gateway JWT authorizer, the AWS-built-in kind, configured with exactly two things:
- an issuer of
https://login.microsoftonline.com/{tenant}/v2.0, and - an audience equal to the Echo API's own app registration.
That is the entire trust configuration. An AWS resource, gated by an AWS-native authorizer, that grants access only when presented with a token minted by Microsoft Entra and bound to the signed-in user. No Cognito. No IAM SigV4 signing on that request. No custom Lambda authorizer doing bespoke validation. The AWS platform validates a Microsoft token because, to an OIDC-aware authorizer, Microsoft Entra is simply another standards-compliant issuer.
This is the sentence I want the skeptical AWS architect to sit with: your API Gateway already knows how to trust Microsoft Entra. You have not been told to think of it that way, but the capability has been there all along.
Same identity, the Microsoft side
The same agent, carrying the same identity, also calls the Microsoft MCP server. One agent. One Entra Agent ID. Two destinations in two different clouds, each handed a token scoped to it, each validating that token on its own terms.
This is what makes Entra Agent ID interesting as an identity layer rather than a Microsoft-only convenience. The agent is not "an AWS thing that occasionally phones Microsoft." It is a governed identity in Microsoft Entra (an agent identity created from a blueprint) that happens to be hosted on AWS, and it reaches whatever it is authorized to reach regardless of which cloud the resource lives in. Microsoft's own documentation is explicit that Entra Agent ID works with agents built on non-Microsoft platforms, AWS Bedrock among them. The PoC is just that statement made concrete.
Why this should land for an AWS architect
The instinct to distrust cross-vendor identity is healthy, because most of it historically meant proprietary glue: a connector, an SDK shim, a sync job that copied identities from one directory into another and drifted out of band within a quarter. None of that is happening here.
What is happening is plain OAuth 2.0 and OpenID Connect:
- ✅ The AWS authorizer trusts an OIDC issuer. Entra publishes standard OIDC discovery metadata; the authorizer validates
iss,aud, and signature against it. This is the same mechanism you would use to trust any external IdP. - ✅ The agent acquires resource-scoped, user-bound tokens through a standard on-behalf-of style exchange. The user's sign-in is turned into a token audienced to each specific downstream resource before the call is made.
- ⚙️ The agent runtime does use MSAL Python to perform the exchange. That is not a proprietary bridge between the clouds; it is Microsoft's standards-based authentication library, the same one you would reach for to speak OAuth and OIDC to Entra from any Python application. The wire protocol is still OAuth and OIDC. MSAL is simply the most direct way to speak it from the agent.
If you already federate your AWS workloads to Microsoft Entra ID for human sign-in, this is the next step: it is time for your AI agents to get their identity from there too.
The token exchange, kept in its lane
There is real machinery behind "acts on behalf of the user," and it is worth one honest paragraph rather than a victory lap of acronyms. Before each downstream call, the agent converts the inbound user token into a token scoped to the specific target resource, in-process, using MSAL Python. The result is a token whose audience is the AWS Lambda for the Lambda call, and the MCP server for the MCP call, with the original user identity preserved throughout. The two-stage exchange that Entra Agent ID uses to do this is documented here; it is the plumbing, not the headline. The headline is that the user's delegated context survives the entire trip, across clouds, to the downstream resources. And this chain can be infinite hops long.
The security posture, briefly
A few properties matter more than the rest:
- 🔐 The agent never hands a credential to the model. Tools return only their response payloads; the inbound token lives in a tightly scoped variable that is cleared in a
finallyblock after every invocation and never reaches the LLM. - 🔍 Tokens are never logged. Only non-secret routing claims (issuer, audience, app id, scope, and the user's object id as a cache key) are emitted, never a token, header, or signature.
- The blueprint credential is read once per process and dropped from memory immediately after the client is constructed.
And the honest production caveat, because a PoC that hides its rough edges is selling something: this sample authenticates the agent's blueprint with a client secret, which is fine for a demo and explicitly not recommended for production. The production path is a certificate or, better, a managed identity used as a federated credential so there is no stored secret at all. I have made the broader case for a secret-less agentic platform before.
What's next, and the thesis
The current PoC still keeps one secret on the AWS side: the blueprint credential. The next step closes that gap in the most fitting way possible: register AWS's own STS as a federated identity credential the Entra blueprint trusts, and let AWS issue the token that proves the agent's identity to Microsoft. At that point the loop is closed in both directions. AWS resources trust Microsoft-issued tokens, and Microsoft trusts AWS-issued tokens, with no shared secret anywhere between them.
That is the whole thesis, and it is smaller than it sounds: a resource trusts a token, not a cloud. The delegation semantics that have governed middle-tier APIs for years did not change when the middle tier became an AI agent, and they do not change when that agent moves to AWS. An identity is a protocol boundary. If your Lambda can trust Microsoft Entra Agent ID, your agent can run anywhere.
References
- astaykov/agentid-agentcore (the PoC)
- What is Microsoft Entra Agent ID?
- Authenticate and acquire tokens for autonomous agents
- Best practices for Microsoft Entra Agent ID
- Create an agent identity blueprint
- Microsoft identity platform and OAuth 2.0 On-Behalf-Of flow
- MSAL for Python
- MSAL overview
- Get started with the Microsoft MCP Server for Enterprise
- AWS Bedrock AgentCore Runtime
- AWS Bedrock AgentCore Identity
- Control access to HTTP APIs with JWT authorizers (API Gateway)
- Develop HTTP APIs in API Gateway
