Part 23 · One Agent, Five Platforms

Security teams tend to ask one question before any other about an agent: which identity does it use? If the answer is "a service account someone set up" or "whoever is logged in", the review usually stops there.

Part 22 showed how Azure answers it. AWS is the last build, in Parts 24 and 25, but its identity model is worth putting next to Azure's now, because the two clouds take noticeably different routes to the same goal. This part compares them, neutrally and in one picture.

It's based on Microsoft Learn and the Amazon Bedrock AgentCore and AWS Well-Architected documentation as I read them on 11 November 2026, linked below.

Agent identity on Azure and AWS, side by side

Two ways an agent can act

Every agent call happens as somebody. There are two basic choices:

  • As itself. The agent has its own identity and its own permissions. Logs show the agent did it.
  • On behalf of a user. The agent carries a person's identity, usually through a token exchange, and acts within that person's permissions. Logs should show both.

Both clouds support both. The design question is which one each call should use, and the risky answer is the one where the agent borrows a user's credentials without the logs showing it was an agent.

Azure: an Entra identity per agent

From Part 22 and the Foundry agent identity page:

  • Where it lives: Microsoft Entra, the same directory as your people. Each new Foundry agent gets its own agent identity from a blueprint.
  • Credential: none stored. A federated credential sits on the blueprint, and the page says the project and agent code "never hold the credential".
  • Least privilege: a new identity starts with no permissions. Tokens are issued per target audience, and Azure RBAC is granted at the narrowest scope.
  • On behalf of a user: supported for some tools. The agent identity acting on behalf of the user is marked preview.
  • Policy: Conditional Access for agents applies the same kind of policies used for people, with extra licensing. Agents using API keys bypass it.
  • Audit: Entra sign-in and audit logs, filterable by agent.

AWS: a workload identity plus an IAM role

AgentCore Identity is described as an identity and credential service built for agents. Its terminology page explains the model:

  • Where it lives: an agent identity directory, described as working "similar to Cognito User Pools". Agent identities are workload identities with agent-specific attributes, each with its own ARN. The page says they let agents "authenticate as themselves rather than impersonating users".
  • Credentials for outside services: a token vault holds OAuth tokens and API keys, encrypted with AWS KMS keys. A token can only be read by the same agent and user combination that obtained it.
  • On behalf of a user: the on-behalf-of token exchange, added in April 2026, swaps a user's token for one scoped to a downstream service, using RFC 8693 or RFC 7523 depending on the identity provider. The new token carries both the agent's and the user's identity.

There's a second layer that Azure doesn't separate in the same way: the IAM execution role. The Runtime permissions page says AgentCore Runtime assumes this role to run the agent. Its trust policy limits which account and resources can assume it, and its permissions cover pulling the image, logs, traces, model calls and getting workload tokens.

Two details worth knowing:

  • Inbound auth to a runtime is either IAM SigV4 or a JWT from your identity provider, not both on the same version.
  • One API issues tokens from a caller-supplied user ID without checking it with an identity provider. The permissions page recommends denying it in production and using the JWT-based exchange instead.

The Well-Architected Agentic AI Lens adds useful vocabulary. It separates four layers: the agent identity, the service identity (the IAM role), the transaction identity (short-lived session credentials) and the user identity (claims passed through the chain). It recommends starting the role with no permissions and adding a permission boundary as a hard ceiling.

Side by side

  • The agent's own identity: Entra agent identity on Azure; AgentCore workload identity on AWS.
  • What it's allowed to do: Azure RBAC on the agent identity; the IAM execution role, plus resource policies, on AWS.
  • Stored secrets: none for the agent itself on Azure; outside credentials sit in the AgentCore token vault on AWS.
  • Acting for a user: delegated access where the tool supports it on Azure; on-behalf-of token exchange with both identities in the token on AWS.
  • Policy on the agent: Conditional Access on Azure; IAM conditions, permission boundaries and service control policies on AWS.
  • Audit: Entra sign-in and audit logs on Azure. On AWS, the AgentCore Identity features page says all operations are logged with context. It doesn't name the logging service, so check that before you design reports on it.

Neither is simply better. Azure puts the agent in the same directory and policy engine as people. AWS splits identity into layers, which is more to configure but gives finer control per call.

What the invoice agent needs

For this series, three rules, on either cloud:

  1. The agent reads and proposes as itself. The six read tools and the process APIs from Part 7 see the agent's own identity, with read-only permissions until Part 9's later stages.
  2. The approver approves as themselves. The approval from Part 6 is recorded with the approver's identity. The agent never holds a token that lets it approve.
  3. The posting carries both. post_invoice_adjustment runs as the agent, with an approval_id that names the person who approved. The process API checks both. That's the audit trail a finance team needs: which agent proposed, which person approved, which system posted.

What to avoid on both clouds: one shared service account for every agent, API keys where an identity would work, and an agent using a person's token for writes.

Parts 24 and 25 build the agent on AWS and give it scores.

Do your agents have their own identity?

This series describes a reference build on a fictional company. This part is based only on Microsoft Learn and AWS documentation as of 11 November 2026; no hands-on build has been run yet. Views are my own. Check current docs before you build.