Why Agent Identity Should Not Ship with the Model
A Reflex, and Why It's the Wrong One
When Microsoft launched Agent 365 last week, my LinkedIn lit up with a version of the same question: "Is this game over for everyone else building in this space?"
It's the right question to ask. It's also the wrong frame.
The reflex when a hyperscaler enters your category is to compare features. Agent 365 has identity, permissions, audit, governance. So does Vorim AI. So do the other companies in our category. Comparing feature lists misses what's actually being decided.
The real question is not "whose product is best." It's "where does the trust layer for AI agents belong in the stack?"
I want to make the case that it does not belong inside the platforms that build, run, and observe agents. It belongs underneath them.
The Pattern from Past Identity Layers
Every previous generation of identity infrastructure ended up in roughly the same place: an independent issuer, separated from the consumers of the identity it issues. Not by accident. By design.
DNS is not run by Cisco, AT&T, or Verizon — the network operators whose packets depend on it. ICANN and the regional registries operate it independently because the alternative — letting one telco own the root — was unacceptable to every other telco.
TLS certificates are not issued by browser vendors. Google does not run a CA that hands out certificates for the open web, even though Chrome consumes those certificates. Browser vendors specifically pushed for an independent CA ecosystem because if Microsoft owned the CAs, Mozilla and Apple would not consume them. The system works precisely because the issuer is not a consumer.
Human identity (Auth0, Okta) became a category outside the cloud providers — even though every cloud provider has IAM — because customers running on multiple clouds and SaaS surfaces did not want any one cloud to be their identity backbone for the rest of their stack.
- The issuer must be neutral with respect to the consumer.
- The protocol must be open so multiple parties can verify the same identity without trusting each other.
- The standard must be governed externally so no single vendor can shift the ground.
Agent identity is a fresh instance of this pattern. Same logic, new substrate.
What Microsoft Agent 365 Actually Is
Before I make the argument, let me be fair about what Microsoft shipped.
Agent 365 is a control plane for AI agents inside the Microsoft 365 tenant. It uses open protocols where it can — OAuth 2.0, OpenID Connect, MCP, A2A. It registers agents, applies Defender policies, runs Purview compliance, ties everything to Entra. The licensing is per-human-user — $15/month standalone, or $99/month bundled in M365 E7. All agents acting on behalf of a licensed user are covered.
It is genuinely good infrastructure for one specific job: governing AI agents inside an organization that already runs on Microsoft.
That job matters. Most enterprise IT runs on Microsoft. Agent 365 will become the default identity surface for those organizations, and it should. I am not making the argument that Microsoft is wrong to ship it.
I am making the argument that this is not the same job as being the issuer of agent identity for the open agent economy. Those are two distinct layers of the stack.
What "the Open Agent Economy" Actually Means
In 2024, most agents lived inside one company's deployment. In 2026, that has stopped being true. The shift happened faster than most security teams have noticed.
A LangChain agent calls an MCP server published by a third-party SaaS company. A CrewAI workflow delegates a sub-task to an OpenAI Assistants agent running on AWS. A commerce agent built on Anthropic's API negotiates a refund with a customer service agent built on Google's Vertex. An audit agent at a bank verifies a counterparty's KYC agent at a fintech.
This is the actual current state of agent deployments. Not hypothetical.
- Is the agent on the other end who it claims to be?
- Has its identity been revoked?
- What permissions does it currently hold?
- Can I verify all of this without trusting the other organization's vendor?
When the trust question is between Acme Corp and Beta Inc, neither will accept Microsoft — or any single vendor — as the source of truth. For the same reason banks did not accept "Citibank's signature on Citibank's transaction" as proof of authorization between counterparties.
Cross-organization agent trust requires a layer that sits below all the organizations involved. That layer cannot be one of the consumers.
Why This Matters More Than It Sounds Like It Does
The pushback at this point usually goes: "Cross-organization agent transactions are rare. Most agent activity is intra-tenant. You're optimizing for a niche."
That was true twelve months ago. It is not true now. Three signals from the last 90 days:
One. Adobe shipped MCP as the default agent protocol for Adobe Commerce in April. The agents browsing, buying, and refunding through Adobe's platform are not Adobe's agents — they're customer agents, partner agents, third-party shopping agents. Each one needs to identify itself to Adobe. Adobe is one of fifty platforms going through the same shift this year.
Two. OpenAI's Workspace Agents and Anthropic's Managed Agents both ship with persistent memory and the ability to delegate to other agents. The handoff doesn't stop at the boundary of one Anthropic or OpenAI account. Agents collaborate across them.
Three. A2A v1.2 introduced cryptographically signed agent cards in April. The protocol's authors — Google and the Linux Foundation — explicitly designed for inter-organizational agent interactions. They added cryptographic identity because the agents calling each other are not in the same trust domain.
The cross-organization case is not the niche. It is the direction the entire industry is pointing.
What an Open Agent Identity Layer Needs
If we accept that agent identity will look more like DNS or TLS than like Active Directory or Entra, the requirements are pretty specific:
Verifiable without the issuer's permission. A counterparty must be able to verify an agent's identity, status, and permissions through a public API, with no shared secret or vendor-issued token between them and the issuer. If verification requires trusting the issuer's authentication system, the issuer is a counterparty.
Revocable in real time, propagated everywhere. When an agent is compromised, every party that ever transacted with it must be able to detect the revocation within seconds. Centralized revocation lists work. Tenant-specific revocation lists do not, because they're invisible across tenant boundaries.
Auditable independently. When something goes wrong, the audit trail of an agent's actions must be verifiable by a regulator, a counterparty, or an arbitrator without privileged access to the issuer's database. The trail's integrity must be cryptographic, not "trust the database."
Specified openly. The protocol must be documented in a venue (IETF, W3C, or similar) where any vendor can implement it without permission, and where changes require multi-vendor consensus. A vendor-specific spec — even one that uses open primitives like OAuth — does not meet this bar, because the spec itself can change at the vendor's discretion.
Multi-cloud and model-agnostic. Agents run on every cloud and every model provider. The identity layer cannot privilege one of them.
Microsoft's Entra Agent ID meets the first three on a technical level. It does not fully meet the fourth: the spec is Microsoft's, registry behavior is Microsoft's, and the verification surface is Microsoft's. It partially meets the fifth, but the licensing model — per-human-user — is a strong gravitational pull back into the Microsoft ecosystem.
This is not a criticism of Microsoft. It is a description of what kind of layer they shipped. They built the right thing for their job.
What the Layer Should Look Like
An open agent identity layer for the agent economy should have a few specific properties.
It should issue identity at registration time, before any control plane sees the agent. It should use open cryptographic primitives — Ed25519 keypairs, signed audit chains — that any vendor can implement without permission. It should publish a public Trust API that any third party can query without authentication. It should be governed by an external body — IETF, the Linux Foundation, or similar — so no single vendor can shift the spec.
It should also be free at the entry point. Identity infrastructure that costs money to verify becomes infrastructure only large vendors can afford to use. The open agent economy will not be one where verifying a counterparty agent costs ten cents per check.
Vorim AI publishes VAIP — the Vorim Agent Identity Protocol — at the IETF as draft-nyantakyi-vaip-agent-identity-01. The spec is MIT-licensed, freely implementable, and competing implementations are explicitly welcomed. Other groups have submitted parallel drafts. The standards space is genuinely contested, and that's healthy. The agent economy benefits from convergence, not consolidation.
What I am hoping for is not that Vorim AI becomes the only implementation. It is that VAIP, or a successor protocol shaped by the same principles, becomes one of three or four interoperable implementations — with Vorim AI as the canonical reference. The same shape as Let's Encrypt within the broader CA ecosystem: not a monopoly, just the trusted, free-tier, open implementation that anyone can verify against.
What This Means for You
If you're a security or platform leader at a company shipping AI agents, the framing that matters is not "which vendor's product?" It is "which layer of the stack do I want to vendor-lock?"
Locking the control plane to a vendor is reasonable. Most enterprises already locked their identity provider to Microsoft, Okta, or Google a decade ago. The control plane question is real, but it has historical precedent and known tradeoffs.
Locking the issuer of identity itself — the layer that other companies' agents need to verify when they interact with yours — to a single vendor is a different decision. It compresses your future optionality in a way that is not obvious until you try to do something that crosses the vendor's boundary.
The best time to make that decision deliberately is now, before it becomes a default.
If you're working on agent identity, agent-to-agent trust, regulated agent commerce, or interoperable audit standards — even if you compete with us — I'd like to talk. Standards before lock-in. The agent economy is too important to ship with the model.
---
Vorim AI provides cryptographic identity, scoped permissions, and tamper-evident audit trails for AI agents. The free tier supports 3 agents and 10K events/month — no credit card. Get started at [vorim.ai](https://vorim.ai), or read the VAIP draft at [datatracker.ietf.org](https://datatracker.ietf.org/doc/draft-nyantakyi-vaip-agent-identity/).
Ready to build with agent identity?
Free plan: 3 agents, 10K auth events/month, full SDK access. No credit card.