Every enterprise has a drawer full of static API keys it pretends are under control. They are not.
A static API key is a bearer credential in the purest sense: it does not know who is using it, does not bind to a caller or a session, and does not expire unless someone remembers to set a date. It grants access to anyone who holds it, full stop.
And keys never stay where they are supposed to. They travel in plaintext emails, get committed to source control in .env files that .gitignore was supposed to catch, get pasted into wiki pages and Slack messages during incident response, and settle into CI/CD pipeline definitions that predate the team's current secrets-management policy. None of this is negligence. It is structural: the tooling makes keys trivially easy to mint and almost impossible to track once they leave the admin console. The result is technical security debt that compounds silently. Keys issued for a proof of concept three years ago are still valid, still embedded in a pipeline nobody touches, still granting day-one access. Revoking them is a game of "what breaks?" that nobody volunteers to play.
This is the foundation too many organizations are building their agentic platforms on. A foundation made of sand.
Managed Identities for Azure resources: the first answer
If your workload runs on Azure, the answer has existed for years: Managed Identities for Azure resources.
A managed identity is a service principal in Microsoft Entra ID whose credentials are entirely platform-managed. Your code never sees a secret, never stores a certificate, never rotates anything. The compute resource requests a token from the local metadata endpoint; Entra issues one. The credential that backs it is inaccessible to anyone, including the team that deployed the workload.
Three properties make this the default choice:
- Complete elimination of static credentials. No API key to leak, no connection string to embed, no vault entry to maintain. The identity is the credential. This is not "better secrets management." It is the absence of secrets.
- Automatic credential lifecycle. Rotation, renewal, and revocation happen without human intervention. No calendar reminders, no runbooks, no incidents when someone forgets.
- Lifecycle binding (system-assigned). When the Azure resource is deleted, the identity is deleted with it. No orphaned service principals, no zombie credentials. User-assigned managed identities offer an independent lifecycle model for workloads that span multiple resources.
The conclusion is not nuanced: if your workload runs on Azure, you should be using a managed identity. Every client secret stored in Key Vault "for safety," every certificate rotated on a quarterly schedule, is a choice to do things the hard way when a safer path is right there. Managed identities are not a best practice. They are the baseline.
Workload Identity Federation: the cross-cloud, cross-provider standard
Managed identities solve the problem when your workload runs on Azure. But workloads do not stay neatly inside one cloud. A GitHub Actions pipeline needs to deploy to Azure. A service on AWS needs to call Microsoft Graph. A Kubernetes cluster on GKE needs to reach an Azure Storage account.
This is where Workload Identity Federation (WIF) enters the picture. WIF is not a Microsoft product. It is a pattern built on open standards: OpenID Connect for identity assertions and RFC 7523 for the JWT bearer token exchange. Instead of handing a workload a long-lived secret, you let it prove who it is using a signed JWT from an identity provider the receiving system already trusts. GitHub, Google Cloud, AWS, Kubernetes, and SPIFFE/SPIRE all issue OIDC-compliant tokens that participate in WIF flows today.
Microsoft Entra supports WIF in both directions, and this bidirectional capability is what makes the rest of this story possible:
Outbound (Entra as issuer). Your tenant issues JWTs that external systems can validate and trust, enabling Entra-authenticated workloads to call services outside the Microsoft ecosystem without static credentials. The earlier article in this series explored exactly this: an AI agent using its Entra-issued JWT to authenticate to Anthropic's Claude API through WIF, with no API key involved.
Inbound (Entra as relying party). Your tenant trusts JWTs from external identity providers and exchanges them for Entra-issued access tokens. This is what lets a GitHub Actions workflow or an AWS Lambda function access Entra-protected resources without a stored secret. The supported scenarios span AKS, EKS, GKE, GitHub Actions, Azure DevOps, SPIFFE/SPIRE, and any platform with an OIDC-compliant identity provider.
Federated Identity Credentials: the inbound trust mechanism
The inbound direction of WIF in Microsoft Entra is implemented through Federated Identity Credentials (FICs). A FIC is a configuration object attached to an app registration or a user-assigned managed identity that tells Entra: "when a JWT arrives from this issuer, with this subject, for this audience, treat it as a valid credential and issue an access token."
Three properties define the trust: issuer (the external IdP's URL, matched against iss), subject (the external workload's identifier, matched against sub), and audiences (typically api://AzureADTokenExchange). All matching is case-sensitive. When an external workload presents a JWT, Entra validates the signature against the issuer's published OIDC keys, checks the claims, and issues an Entra access token. No secret involved. No certificate involved. The trust is cryptographic and scoped to exactly one external workload.
The mental model: there must be a workload identity in Entra (app registration or managed identity) that trusts the external token and represents that workload within the Entra ecosystem. The external workload never gets a secret; it gets a trust relationship. (Design note: a maximum of 20 FICs can be configured per app registration or managed identity.)
Managed identity as a federated credential: the elegant twist
Managed identities eliminate secrets on Azure. FICs eliminate secrets for external workloads. But what about scenarios where you need an app registration (because the downstream API requires it, because your token needs specific optional claims) and yet you still want zero secrets?
The answer: configure the app registration to trust a managed identity as its federated credential. The workload acquires a managed identity token from the local metadata endpoint, presents it to Entra as a FIC on the app registration, and receives an access token scoped to the app. No client secret. No certificate. The managed identity is the credential. The managed identity handles the credential lifecycle; the app registration handles token shape, optional claims, and API permissions. Each does what it is good at, and no secret sits between them.
The convergence: Agent Identity Blueprints without secrets
Now bring in Microsoft Entra Agent ID.
An Agent Identity Blueprint is the authentication foundation for one or more agent identities. The blueprint holds the credentials and acquires tokens on behalf of all agent identities created from it. Conditional Access policies applied to the blueprint propagate to every agent identity it parents. It is, by design, the central point where credential management happens for an entire family of AI agents.
In the simplest deployment model, a blueprint holds a client secret. For production, teams typically upgrade to a certificate. Both are secrets that must be stored, rotated, and protected. Both are liabilities.
But a blueprint is, at its core, backed by an app registration in Microsoft Entra. And we just established that an app registration can trust a managed identity as its federated credential.
The implication is direct: configure a managed identity as the federated identity credential on the blueprint's underlying app registration, deploy the agent runtime on Azure compute with that managed identity assigned, and the blueprint acquires tokens using the managed identity token exchange. No client secret. No certificate. No vault. The managed identity, lifecycle-bound to the Azure compute resource, is the only credential in the system.
Three concepts, designed independently for different purposes, converge into a single architecture: Managed Identities provide the credential-free primitive for Azure compute. Workload Identity Federation extends it across trust boundaries via OIDC and RFC 7523. Federated Identity Credentials bind an external identity (including a managed identity) to an Entra workload identity, replacing secrets with cryptographic trust.
Applied to an Agent Identity Blueprint, these three deliver a secret-less agentic platform. Not a roadmap item. Not a preview. A production-ready architecture available today, using generally available constructs in Microsoft Entra ID.
If you are building an agentic platform in 2026 and your agents still hold secrets, the question is no longer "should we fix this?" The question is "why haven't we?"
References
- Managed identities for Azure resources overview
- Workload Identity Federation
- Federated Identity Credentials overview (Microsoft Graph)
- Configure an app to trust a managed identity
- Microsoft Entra Agent ID design patterns
- Agent Identity Blueprints
- RFC 7523 — JWT Profile for OAuth 2.0 Client Authentication and Authorization Grants
- OpenID Connect
