Microsoft Entra workload identity — managed identities and workload identity federation — authenticates Azure-hosted and federated workloads without a stored client secret, using platform-attested properties instead. For AI agents running on Azure or federating in from another platform, this removes a real class of standing-credential risk. It is a transport and infrastructure-authentication answer, not an agent-identity answer, and Microsoft's own roadmap reflects that split by building a separate product, Entra Agent ID, for the logical-agent layer.
What Entra workload identity actually provides
A managed identity is an identity Azure automatically manages for a resource — a virtual machine, a container app, an Azure Function — so that resource can authenticate to other Azure services without a developer ever provisioning or rotating a credential for it. The platform handles issuance and rotation; the workload simply requests a token when it needs one, and Entra ID verifies the request based on the resource's own Azure identity rather than a stored secret.
Workload identity federation extends the same secretless model to workloads that don't run inside Azure at all: a Kubernetes service account, a GitHub Actions pipeline, or a workload in another cloud can present an OIDC token from its own trust source, and Entra ID trusts that token — configured through a federated credential — in place of a client secret, issuing an Azure access token in exchange. This is the same category of pattern as SPIFFE-based workload identity generally: attest to a verifiable property of the workload, issue a short-lived credential, no static secret involved. See mTLS, SPIFFE, and workload identity for agents for the underlying model.
For an agent runtime hosted on Azure — as a container app, on a VM, or in AKS — this means it can authenticate to Azure OpenAI, Azure resource APIs, or any other Azure service it needs without a secret sitting in its configuration. For an agent hosted elsewhere that needs to reach Azure resources, federation removes the need for a static Azure credential to be distributed to that external environment at all.
What workload identity establishes, and what it doesn't
Workload identity in Entra answers: this token request comes from a workload the platform (or a trusted external OIDC issuer) attests to be a specific, known resource. That is a resource-level identity, evaluated at the level of "which Azure resource," not "which logical agent."
The gap is the same one that shows up with every workload-identity system, examined generally in machine identity vs. workload identity vs. agent identity:
Many agents can share one workload identity. If ten agents run inside the same container app or App Service instance, they present the same managed identity to Azure. Distinguishing which of the ten made a given call requires an application-level agent identity carried in the request, independent of which Azure resource is hosting it — Entra ID's managed-identity model authenticates the resource, not the individual agents sharing it.
On whose behalf is a separate question from the token request. A managed identity's token proves which resource is calling; which end user's task the current request serves is a separate fact the token doesn't carry. Authorizing purely on the workload identity reproduces the confused deputy problem at the Azure-resource level: any user whose request happens to route through that resource inherits whatever the resource's identity is entitled to.
Delegation-chain narrowing is a separate layer. An orchestrator agent using its managed identity to call a downstream service, which then triggers a sub-agent, needs a mechanism above Azure's own model to narrow the authority passed down that chain. Azure's managed identity model authenticates each hop's own resource identity; constraining a chain of delegated authority across hops is what an application-level token-exchange pattern adds on top — see scoped tokens for sub-agent delegation.
Tool-call-level scoping is a separate governance layer. A managed identity's role assignments in Azure RBAC are scoped to Azure resources and operations — read this storage account, write to that database. Extending that to "which specific tool on an MCP server this agent may call" is a governance layer above Azure's own IAM, covered in scoping MCP tool permissions.
Where Entra Agent ID fits
Microsoft's response to the logical-agent gap is a separate, purpose-built product rather than an extension of workload identity's existing model: Entra Agent ID, part of Microsoft's broader agent governance toolkit, is built specifically to give AI agents their own identity object distinct from the infrastructure they run on — closer in spirit to how a human user has an identity distinct from the VM they happen to log in from. That product, and Microsoft's Purview and governance-toolkit work around it, is covered in depth in Microsoft's agent governance toolkit and independent control planes, including where its own coverage boundary sits relative to non-Microsoft agents and tools.
The practical takeaway for an Azure-hosted agent estate: workload identity (managed identities and federation) is the right choice for removing standing secrets between agent infrastructure and Azure services, and it should be adopted regardless of what else you run. Entra Agent ID, or an equivalent logical-agent identity layer, is the separate piece that answers which agent, acting for whom — and it is not a substitute question workload identity was ever meant to answer.
A layered summary
| Question | Entra workload identity | Entra Agent ID / logical-agent layer |
|---|---|---|
| Is this request from a known, attested Azure resource | Yes | N/A |
| Which specific agent, among several sharing that resource, made this call | Out of scope for workload identity | Yes |
| On whose behalf is this call being made | Out of scope for workload identity | Depends on integration with delegation/token-exchange |
| Which Azure resources may this workload reach | Yes, via Azure RBAC | N/A |
| Which specific tool call is authorized for this task | Out of scope for both | Requires a policy layer above both |
What good looks like
- No client secrets for any Azure-hosted or Azure-connecting agent workload where a managed identity or federated credential can be used instead.
- External agent runtimes reach Azure resources through workload identity federation rather than a distributed static credential.
- Each logical agent has an identity distinct from the Azure resource hosting it, so co-located agents remain individually attributable.
- Azure RBAC role assignments for agent-hosting resources follow least privilege at the resource level, complemented by a separate tool-call-level policy layer for MCP and API access.
- Delegation between agents narrows scope at each hop, tracked at the application layer rather than assumed from the shared workload identity.
Multi-cloud reality check
Very few agent estates run exclusively on Azure, and workload identity federation's cross-cloud reach has a direction worth stating plainly: it federates into Entra ID, letting an external workload obtain an Azure token. The reverse direction is configured on the other cloud's side — an Entra-issued OIDC token can serve as the identity source for AWS IAM's OIDC federation or GCP Workload Identity Federation, but that trust relationship has to be set up there, not in Entra, or through a platform-independent layer like SPIFFE that both sides trust. An agent estate spanning Azure, AWS, and GCP typically ends up running each cloud's native workload identity for calls into that cloud, plus a federation or SPIFFE layer for the connective tissue between them, rather than expecting any single cloud's workload identity product to cover the whole estate — the same platform-independent naming argument made for SPIFFE in mTLS, SPIFFE, and workload identity for agents, and a factor worth weighing against AWS's own approach in AWS Bedrock AgentCore Identity explained.
Budget for this explicitly rather than discovering it mid-build: a design that assumes "we're on Entra, so workload identity is solved" for an estate that also touches other clouds will hit the boundary the first time an agent needs to reach a non-Azure resource without a static credential.
Common questions
Does Entra workload identity remove the need for a secrets vault? For the specific case of a workload authenticating to Azure services, yes — it removes the client secret from that path entirely. Agents still commonly need credentials for non-Azure, non-Microsoft downstream systems, where a secrets vault or the exchange pattern described in secrets management for AI agents still applies.
Is workload identity federation only useful for CI/CD pipelines? No — federation is commonly associated with CI/CD (GitHub Actions authenticating to Azure without a stored secret is a widely used example), but the same mechanism applies to any external workload with its own OIDC-issuing identity source, including agent runtimes hosted in Kubernetes clusters or other clouds that need to reach Azure resources.
How does Entra workload identity relate to SPIFFE/SPIRE? They are the same category of solution — attested, secretless workload authentication — built by different parties for different scopes. Entra's version is native to Azure and Microsoft Entra ID; SPIFFE is platform-independent and commonly used to unify identity across Kubernetes, VMs, and multiple clouds, as described in mTLS, SPIFFE, and workload identity for agents. Organizations spanning both Azure and other platforms often federate between the two rather than choosing one exclusively.