The industry has reached rough agreement on the problem. AI agents act, often dozens of times from a single instruction, and every action is an authentication and authorization event. So each agent needs its own distinct identity, scoped permissions, a named human who is accountable for it, and an audit trail. That much is now common ground across identity vendors, cloud platforms, and at least one national government.
Where the field disagrees is on how to do it. One approach issues each agent a token from a central identity provider. The other gives each agent a portable credential it carries and presents. The difference looks like an implementation detail. It decides whether agent identity becomes a standard or a set of vendor islands.
The identity-provider model, described plainly
The most fully formed version of the first road is Microsoft Entra Agent ID, so it is worth describing accurately rather than as a strawman. An agent gets a dedicated identity in the directory, distinct from human users and generic service accounts. It holds no credentials of its own; it obtains tokens through a blueprint that issues federated credentials, which lets an administrator apply policy across many agents at once. When the agent calls a tool, the platform issues an access token scoped to that resource's audience, and the downstream service validates the token and checks the agent's role assignments before allowing the action. It supports OAuth 2.0 on-behalf-of and client-credentials flows, and it works with the open agent protocols, MCP and A2A. As an account of how an agent authenticates inside one organization's cloud, this is solid engineering, and the security advice that comes with it — least privilege, short-lived federated credentials instead of long-lived secrets, a named sponsor for every agent — is correct and worth following.
The limits are not bugs in the implementation. They are properties of the model.
What the model cannot do, by design
Trust terminates at the issuer. Every verification in this model runs through the identity provider: the platform validates the credential and mints the token, and the downstream resource trusts the token because it trusts the issuer. A party that does not trust that issuer has no way to verify anything. Inside one company that is fine, because everyone already trusts the corporate directory. Between companies, it is the whole problem.
The tokens are bearer tokens, not portable authority. An access token says the bearer may call this audience right now. It is not a signed, self-contained statement of what authority was granted, by whom, under what limits, that a third party can check on its own. To learn what an agent was actually permitted to do, you ask the issuer. The proof is not in your hand; it is in their system.
And the boundary is explicit in the documentation. Agent identities in this model can only be issued tokens in the tenant where they were created and cannot reach resources in other tenants. Cross-organization use is handled by publishing a multitenant blueprint that creates a separate, tenant-local agent identity in each other organization. That is not one portable identity crossing a boundary. It is a copy minted per tenant, each bound to the issuer that minted it. The vendor's own guidance also notes that once a tool call leaves the provider's services, data handling and retention fall to the external provider. Governance holds inside the tenant and stops at its edge.
Why this matters for standardization specifically
Agents do not stay inside one organization. A procurement agent at one company negotiates with a sales agent at another. A logistics agent acts across a supplier it has no account with. A regulator needs to verify, after the fact, what a deployer's agent was authorized to do, without taking the deployer's word or querying the deployer's directory. These are the cases that make agent identity hard, and they are exactly the cases the issuer-bound model cannot serve without everyone first agreeing to trust the same issuer.
A standard whose guarantees only hold inside a single vendor's tenant has not standardized the thing that needed standardizing. It has standardized configuration. The point of a standard is that two parties who share no infrastructure and no prior trust can still interoperate, because the format and the cryptography carry the guarantee, not a shared platform. If agent identity fragments into per-vendor token systems that each work only inside their own walls, the industry will have spent its standardization effort and produced interoperability with itself. The test for any agent-identity standard is simple: can a third party who does not trust your issuer still verify what your agent was authorized to do? If the answer requires calling your issuer, it is not cross-organizational, and if it is not cross-organizational, it is not a standard.
The other approach
The alternative is to make the authority itself portable. Express what an agent may do as a signed credential the agent carries and presents, verifiable offline by anyone holding the issuer's public key, with no callback to the issuer at verification time. This is the W3C model: Decentralized Identifiers for self-controlled identity that is not minted by and bound to one provider, and Verifiable Credentials for portable, signed, scoped grants that a counterparty can check independently. Trust comes from the cryptography and the open format, not from a platform both sides have to be inside of.
This is the layer we work in. The Agent Authorization Envelope, published as an IETF Internet-Draft (draft-kroehl-agentic-trust-aae-00) and expressed over W3C DIDs and Verifiable Credentials, is a signed, portable statement of an agent's mandate, its constraints, and its validity — built to be verified by a counterparty that shares none of your infrastructure and has no reason to trust your issuer. We named the underlying paper Trust Without Trusting for that reason: the goal is verification that does not require the verifier to trust the party being verified.
The honest boundary
None of this makes the issuer-bound model wrong everywhere. For agents that live entirely inside one organization's cloud, authenticating to that organization's own resources, the identity-provider approach is simpler, mature, and already deployed, and the offline, issuer-independent property buys you little when everyone in the picture already trusts the same directory. If your agents never cross an organizational boundary, the central model is a reasonable choice and probably the easier one.
The fork is the boundary. The moment an agent has to prove its authority to someone who does not share its tenant — another company, a regulator, a counterparty agent — issuer-bound tokens stop being sufficient and portable, independently verifiable credentials become the only thing that holds. That is not a niche case. It is where agent-to-agent commerce, supply chains, and accountability to outside parties all live, and it is the case a real standard has to serve. Building agent identity so that it only works inside one tenant is a decision to solve the easy half and leave the half that needed a standard unstandardized.
The authorization layer, named by a government
Estonia stated the same requirement for AI-agent authority — scope, limits, validity, delegation — and left the enforcing layer open.
Read: Estonia named the problemSources
- Microsoft Learn — Overview of agent identities in Microsoft Entra (single-tenant token issuance; multitenant blueprints create tenant-local identities; sponsor; blueprint / federated credential model)
- Microsoft Learn — Agent identity concepts in Microsoft Foundry (token issuance and validation chain; scoped audience tokens; MCP and A2A authentication)
- Microsoft Learn — Agent OAuth flows, on-behalf-of (supported grant types: client credentials, jwt-bearer, refresh token; no interactive /authorize for agents)
- Microsoft Learn — Manage agent identities (data handling for tool calls that leave the provider's services)
- W3C — Decentralized Identifiers (DIDs) and Verifiable Credentials data models
- Agent Authorization Envelope — IETF Internet-Draft
draft-kroehl-agentic-trust-aae-00 - Trust Without Trusting — A Recomputable Trust Protocol for Autonomous Agents (arXiv:2605.06738)
Note: Microsoft Entra Agent ID is described here as the most fully formed example of the identity-provider model, from its public documentation, not as the only such product. The structural points apply to the issuer-bound token model generally, not to one vendor.
Written by the MolTrust Team (CryptoKRI GmbH, Zurich). Questions or feedback: @MolTrust on X.