Microsoft's Agent ID Is the Directory. It Is Not the Proof.

1. The announcement that landed at RSAC

Microsoft moved Entra Agent ID to GA on Monday at RSAC 2026. Agents built with Microsoft Foundry, Copilot Studio, and the Agent 365 ecosystem partners now receive a first-class directory identity inside the tenant. Conditional Access policies apply to those agents the same way they apply to a human user. Shadow AI detection (via Defender for Cloud Apps) shipped GA in the same release. Tenant Governance and Backup/Recovery moved into preview. The framing was not subtle. The blog post and the keynote both presented Entra as the identity layer for AI agents.

It is, on its own terms, a good release. Anyone who has tried to govern an enterprise full of agentic deployments built on per-app, per-tenant tokens with no consistent lifecycle will look at Entra Agent ID and feel an honest sense of relief. Agents have a record. The record has policy gravity. There is a place to look up what an agent is allowed to do and a control plane that can deny actions the agent is technically capable of taking. Twelve months ago that wasn't true at any scale outside of the most disciplined platform teams.

The piece I want to spend the rest of this essay on is the layer Entra Agent ID does not occupy, why that layer is load-bearing for any agent doing real work, and why the conflation of those two layers is what produced most of the breach copy of the last six weeks.

2. Two questions that keep getting collapsed into one

Anytime an agent talks to a service, two questions are in play. The first is "is this agent allowed to do this thing." The second is "is the entity at the other end of this connection actually that agent." Most architectures answer one of those well and assume the other got handled somewhere else.

Directory-anchored systems (Entra, Okta, Auth0, anything OAuth-shaped at its core) are good at the first question. They model identity as a record, attach scope to that record, and carry policy logic that decides at request time whether the recorded identity is permitted to take the action. Conditional Access is a particularly mature instance of that pattern. When the directory is correctly populated and the policies are well-written, the first question gets a defensible answer.

The second question is structurally different, and it isn't really a policy question at all. It's about whether the bytes coming in over the wire are actually originating from the entity the directory has a record for. The honest way to answer it usually involves cryptography that the holder cannot replay if it leaks, plus a credential lifetime short enough that capturing it later doesn't pay.

When directory people argue with workload-identity people, you can usually trace the disagreement back to one side answering question one and the other side answering question two. They mostly aren't disagreeing. They are operating on different layers of the same stack.

3. What happens when the directory tries to answer both questions

Vercel happened ten days ago. The disclosure walked through a Context.ai OAuth integration with "Allow All" scope against a Vercel-employee Google Workspace account, an attacker pivoting through that integration into Vercel's internal systems, and the exfiltration of a tranche of customer environment variables that, conveniently, were classified as "not sensitive." The CEO acknowledged on day three that the AI-tool OAuth connection was the primary vector. By day five Vercel was confirming additional compromised accounts.

The interesting frame for this article is not the breach narrative. (Plenty of people are doing that work, and we already wrote one of those here.) The interesting frame is what the Context.ai integration token actually was, structurally, and why having a directory record for that integration would not have prevented anything.

An OAuth token is a bearer credential. The protocol is named for the idea: whoever bears the token has the authority. The directory says "this agent has scope X, and we've issued a token that proves it." But the token itself, once minted, is portable. If it leaves the host that minted it, the holder is, for the purposes of every downstream service, the agent. There is no part of the OAuth token presentation that asks "are you the substrate that was supposed to be holding this token." The token is the substrate, until it expires.

Vercel demonstrated that with painful clarity. The Context.ai token was issued legitimately, granted "Allow All" scope by an employee click, and stolen. The replay was, from the directory's perspective, a perfectly authentic action by the agent the directory had a record for. Conditional Access could not save anyone, because the request looked exactly like a request the policy was supposed to permit. Whatever directory hygiene Vercel had at the time wasn't the problem. The problem was that the token answered the wire question by default, and the wire question is not what the directory was designed to answer.

My read is that this is going to keep happening. Not because directory-anchored systems are bad (they're useful), but because the marketing copy keeps suggesting that adding the agent to the directory has solved a problem that was actually somewhere else.

4. What the certificate is for, concretely

A workload-attested X.509 certificate, issued by a private CA the tenant controls, answers the wire question on terms a bearer token cannot. The credential is a key pair. The private half lives in the workload's keystore: a TPM in the well-engineered case, an HSM-backed software keystore in the budget-constrained case, sometimes just a sealed secret on a node with measured boot. The cert itself is signed only after the issuance authority has been shown evidence about the substrate that's asking for it (which host, which deployment, which controller spawned the request). The TTL is measured in hours, and often in minutes for ephemeral CI work.

Replay of the certificate alone doesn't help an attacker. They'd need the private key, and the private key is bound (in the well-built case) to hardware on the host. Capture of an in-flight TLS handshake doesn't help either, because the handshake proves possession of the key without revealing it. If a compromise does occur, the blast radius is bounded by the TTL. A two-hour cert, captured at hour one, gives the attacker an hour. A ninety-day OAuth token, captured at hour one, gives the attacker ninety days.

There's a piece of vocabulary that gets overloaded in this conversation, and I want to disambiguate it. Workload-identity people often refer to the credential as an X.509-SVID, borrowing from SPIFFE. SPIFFE is a specific spec, and it's good. But the architectural pattern is older than SPIFFE. Any short-lived X.509 client cert, issued after attestation, by a CA the tenant controls, with a defined revocation channel, does what we're describing. Whether you wire that up via SPIRE, cert-manager pointed at your private CA, a Vault PKI engine, or a managed issuance API is an implementation question. The architectural property is that the cert isn't a token.

5. The CSA essay was pointing at the same gap

A week before RSAC, on April 23, the Cloud Security Alliance published an essay titled "We Are Fixing the Wrong Problem in Non-Human Identity Security." The headline argument is that discovery-first NHI tools (the ones that scan your substrate, build an inventory of service accounts, and feed the inventory into governance) cannot keep up with workload populations that turn over faster than the scan interval. The CSA piece doesn't name a vendor and doesn't propose a product. It just says the discovery-first model is the wrong layer.

We wrote a longer response to that essay here. The short version is that the constructive answer to "discovery doesn't work" is enrollment-first issuance, where the inventory is a byproduct of how credentials get minted rather than a separate scanning loop chasing the substrate.

The CSA argument and the Entra Agent ID release are pointing at adjacent gaps. CSA was saying: the NHI inventory layer is structurally too slow. Microsoft is saying: agents need a directory record with policy. Both observations are correct. Neither of them, on its own, addresses the wire question. An enrollment-first issuance flow that produces short-lived X.509 credentials, attested at issuance, is the part that makes the directory record an enforceable claim rather than a hopeful one. Without that issuance layer, the directory record is doing what it's good at, but the connection itself is being authenticated by a token whose security model assumes nobody else has the bytes.

6. The badge and the lock

A clarifying analogy I keep coming back to. Building-access systems already separate these two layers cleanly, and the people who design them stopped arguing about whether one replaces the other a long time ago. The HR system maintains the record of who is allowed in which rooms. The badge reader on the door verifies that the person tapping in possesses the credential the HR record says they should. You don't trust HR alone, because HR doesn't watch the door. You don't trust the door alone, because the door doesn't know whose record to look up.

Entra Agent ID is the HR system for agents. Conditional Access is the policy engine that decides which doors a given agent's record is allowed to open. A workload-attested certificate is the badge in the agent's hand, and the TLS handshake on the service it's calling is the reader on the door. The reader doesn't replace HR. HR doesn't replace the reader. Anyone who has done both jobs simultaneously will tell you the failure modes are different and the controls have to be different.

The implicit pitch in a lot of agent-identity vendor copy right now is that the HR system has been upgraded enough that the door can stop checking. That has never been true for humans. It is not going to be true for agents either.

7. What this changes for the next twelve months

The Entra Agent ID GA is going to harden two things. First, the assumption that an agent has a directory record will become table stakes in any procurement conversation. That's a good shift. Second, the temptation to treat the directory record as the entire identity story will get stronger, because Microsoft's marketing is excellent and Conditional Access is a familiar tool. That second shift is the one to watch.

If you're an architect or a security lead at a mid-market org and your platform team has either committed to Entra Agent ID or is about to, the productive question to bring back to the table is something like: when an agent makes a call to a service that I'm responsible for, what credential is presented at the wire, who issued it, how long is it good for, and what does the receiving service actually verify? If the answer is a long-lived OAuth token signed by Entra and that's it, you have the building-without-doors version of the architecture. The directory record is fine. The wire is undefended.

If the answer is "the agent presents a short-lived client certificate issued by our private CA, the cert chains to a root we operate, the receiving service does mTLS, and revocation is consulted," you have both layers in place. The directory record tells you what the agent is allowed to do. The cert tells you the agent is the agent. Both questions answered, on the layers they belong on.

There's an architectural detail worth being honest about. The cert layer is more work than turning on Entra Agent ID. It requires running a CA (or paying a vendor to run one in a way that preserves your control), wiring cert-manager or its equivalent into your workload substrate, defining attestation policies, and figuring out how revocation propagates. None of those are unsolved problems. They are not free either. The reason most of the industry copy waves at the wire layer is that the wire layer is harder than the directory layer, not because it's less important.

8. What the Score is grading

The [cyphrs] Score grades both layers, intentionally. Directory-side hygiene (whether agents have records, whether scopes are actually minimal rather than nominally minimal) shows up alongside wire-side hygiene (replay-resistance at the handshake, TTL distribution, whether revocation is reachable, whether the validator actually consults it). The reason both are graded is that getting one right while ignoring the other produces the architecture Vercel had on April 19. Looks fine on paper. Catastrophic on the wire.

I'll be specific about what I'm not arguing here. I'm not arguing that the cert replaces the directory record. The directory record is doing real work. I'm not arguing that Entra Agent ID is the wrong release, because it isn't. The problem is the layering claim that gets attached to it in the next twelve months of vendor messaging, where the directory becomes the identity, and the wire-level credential gets relegated to an implementation detail. That's the part that produces the next breach copy.

A useful sentence to carry into the conversations this is going to spawn: Entra Agent ID is the identity record. The certificate is what proves the agent at the other end of the connection is actually that agent. Both belong on the architecture diagram. Neither one stands in for the other.

The directory record is who the agent is on paper. The certificate is what the agent presents at the door. Anyone trying to sell you one as a substitute for the other is probably not going to be the one explaining the breach.