Entra Agent ID Solves Discovery. It Doesn’t Solve Governance.

Agent ID closes the discovery gap. It doesn’t close the one that matters.

Microsoft Entra Agent ID ships with three pillars: manage agents at scale, govern agent identities, protect agent access. Sponsorship. Lifecycle management. Conditional Access. Identity Protection. Network controls.

I read through the architecture. Nine governance mechanisms. Three categories. I counted how many of them evaluate what an agent does after it authenticates.

Zero.

Every mechanism Microsoft shipped operates at the identity layer: who is this agent, who owns it, what can it reach. None of them operate at the decision layer: what is this agent doing right now, with the access it already has, on the four-hundredth API call of the session.

Agent ID does exactly what it was built to do, and it does it well. The risk is how fast organizations will mistake “the agent has an identity” for “the agent is governed.” Those are two different claims, and the space between them is where the next class of breach is going to come from.

“The agent has an identity” is not “the agent is governed.” Those are two different claims, and the space between them is where the next class of breach is going to come from.”

Agent ID Closes the Right Doors. It Doesn’t Watch What Walks Through Them.

Before this ships further into production tenants, give it credit for what it solves.

Agents created through supported Agent ID provisioning paths get a unique, governed identity. No more anonymous service principals running background tasks nobody can attribute. Sponsorship assigns a human owner to every agent, which closes the orphaned-identity problem that has plagued service accounts for a decade. Lifecycle management moves agents through creation, use, and deactivation on a defined path instead of running indefinitely because nobody remembered to turn them off.

The same model pulls in third-party agents built outside the Microsoft ecosystem through the Entra SDK or Microsoft 365 SDK, using a sidecar or workload-federation pattern that places Entra in the token path before those agents touch enterprise resources.

This is real progress. The discovery problem and the attribution problem are two of the oldest failures in identity governance, and Agent ID addresses both directly. If your organization is running agentic workloads today with zero inventory and zero ownership assigned, deploying Agent ID is the correct first move. Not a debate.

It is real progress at the front door. It is not runtime governance.

By runtime governance, I mean inspection and enforcement over what an agent does inside an active session, after a token has already been issued, not only who issued it or what it’s allowed to reach.

“It is real progress at the front door. It is not runtime governance”

This Is an Authentication Problem Solved. Not a Behavior Problem Solved.

Conditional Access evaluates an agent when Microsoft Entra ID issues or refreshes an access token. Continuous Access Evaluation extends that into the session itself. Entra ID can revoke a workload identity’s token in near real-time if an administrator disables the service principal or Identity Protection flags it high-risk. That’s real progress, and it’s worth being precise about: CAE closes the gap between a credential going bad and the system finding out. It does not evaluate what the agent is doing with a credential that still looks healthy. An agent making a routine API call under a token nobody has revoked, that hasn’t triggered a risk signal, and is still well within its lifetime is invisible to CAE by design. The fallacy isn’t that nothing happens after sign-in. It’s that everything happening between sign-in and revocation gets evaluated for credential health, never for behavioral intent.

An autonomous agent doesn’t make one decision per session. It makes thousands.

A workload identity authenticates once, picks up a token, and runs a planning loop: read this file, query that API, draft this output, call that tool, repeat. Deep into that loop, every available control has already done its job. The token is valid. No risk signal fired. The session looks healthy by every measure built to watch it.

If one of those deep-loop actions is the wrong one, because a poisoned document redirected the agent’s plan or because the agent’s reasoning drifted somewhere your prompt never anticipated, your identity stack has nothing left to say about it.

Most identity tools verify that a credential is valid. They were never built to evaluate whether a decision made well past authentication still matches the purpose the credential was issued for.

Why This Breaks Differently Than a Compromised Human Account

A compromised human credential moves at human speed. Someone notices a strange login. A help desk ticket gets filed. Security reviews the access an hour later, sometimes a day later, and the blast radius is whatever one person could touch in that window.

A compromised or hijacked agent credential moves at machine speed. The same token that authenticated once can drive thousands of API calls in the time it takes a human analyst to read one alert.

According to reporting by The Verge and The Information, in mid-March 2026, an engineer at Meta posted a technical question to an internal forum, and a colleague invoked an internal AI agent to help. Instead of returning a private response to the requesting engineer, the agent posted its answer publicly to the forum without consent or approval, and the advice was incorrect. A colleague acted on it, and for roughly two hours, employees without proper clearance had access to sensitive company and user data. Meta classified the incident as SEV1, its second-highest internal severity level. The agent never directly altered access controls. It induced a human to do it by giving wrong but plausible instructions.

“No attacker. No compromised credential. No phishing link.”

The agent had a correctly provisioned identity. Its access, presumably, matched its task scope. None of that mattered, because nothing in the governance model was watching what the agent decided to do with the access it already, legitimately, had.

Static service principals make the identity-layer version of this worse by design. Long-lived secrets, broad API permissions, no expiration date attached to the credential itself. Agent ID’s sponsorship and lifecycle controls reduce how many of those static credentials exist in the first place. They don’t change what happens inside a session once a valid, well-governed, properly sponsored agent picks up a token and starts acting on it.

The Single-Login Fallacy: the assumption that an identity check performed once, at authentication, remains valid for every action an agent takes for the remainder of that session. Every layer of Agent ID’s governance model operates upstream of this fallacy. None of it operates downstream, where the fallacy causes the damage.

The Governance Gaps Agent ID Doesn’t Touch

Five matter most for an architecture conversation, ranked by how fast they turn into an incident.

Decision traceability. Logs show that an agent accessed a file or called an API. They rarely show why. Without a reasoning trail tied to each action, security teams can’t distinguish a legitimate task from a hallucinated one or a prompt-injected one after the fact, only that something happened.

Prompt injection as a trust exploit. An agent that retrieves and trusts external content, an email, a document, a scraped page, risks having its plan redirected by instructions hidden inside that content. The agent’s credential never changes. Its behavior does. Nothing in an identity stack is built to catch it.

Authorization drift in dynamic tool chains. An agent’s permission set is correct on the day it’s provisioned. APIs get updated. Data sources get reorganized. Six weeks later, the scope granted to the agent on day one now reaches data it was never meant to touch, and nobody re-evaluated the grant because nothing about the agent’s identity changed.

Multi-agent collusion. Agent A has access to system one. Agent B has access to system two. Neither agent, individually, does anything out of policy. Put them in the same workflow and they move information between systems in a way neither was individually authorized to do. There is no broadly adopted enterprise identity-governance model that treats a multi-agent workflow as one composite trust boundary instead of two separately authorized identities.

Missing human-in-the-loop checkpoints for high-impact actions. Most agent implementations have no standardized way to pause before an irreversible action, a large payment, a production change, a bulk delete, and route it to a human for approval before the tool call executes. The capability exists in principle. Almost nobody has wired that gate into the orchestration layer where the agent decides to act.

The Field Now Has a Name for This

OWASP published the Top 10 for Agentic Applications in December 2025. Ten categories, ASI01 through ASI10. More than a hundred practitioners and researchers built it specifically because the existing LLM Top 10 doesn’t cover what happens once a system starts acting instead of just answering. The fact that a dedicated framework exists, separate from the chatbot-era list, is the field confirming this risk is no longer theoretical.

Most OWASP Agentic categories originate or materialize downstream of authentication, during tool use, planning, retrieval, or inter-agent coordination. Conditional Access constrains who receives a token and under what conditions. It does not evaluate whether the agent’s next tool call still matches business intent. Not one of them is something Conditional Access evaluates.

This Is a Runtime Governance Failure, Not an Identity Failure

Every gap above shares one trait. The agent’s identity is correct. The agent’s sponsor is correct. The agent’s Conditional Access policy fired correctly at sign-in. The failure happens inside the session, where Entra’s identity-layer controls, including the newer Conditional Access path built specifically for agent identities, judge who the agent is and whether it looks compromised. None of them judge whether a specific action the agent is about to take still matches its purpose.

Identity-layer governance and runtime-behavior governance are two different control planes. Agent ID owns the first one well. Almost nobody owns the second one yet.

“Identity-layer governance and runtime-behavior governance are two different control planes. Agent ID owns the first one well. Almost nobody owns the second one yet.”

What a Greenfield Framework Actually Requires

THE PROBLEM: Identity governance stops at authentication. Agentic risk lives inside the session, after authentication completes.

THE CAUSE: Every available control was built around the assumption that login is the meaningful checkpoint. Agentic workloads broke that assumption without anyone updating the architecture underneath it.

THE SOLUTION: Ten fixes across three phases. The first two close the ownership gap. The third closes the runtime gap.

Most environments I’ve audited can answer two of the next ten questions cleanly. Maybe three.

Phase 1: Identity as the Mandatory Front Door

1. Inventory every service principal and app registration exhibiting agentic behavior, before deploying a single new agent. Do you have one list today mapping every existing agent identity to a named human sponsor?

2. Auto-quarantine any agent identity missing a sponsor field to a sandbox-only scope. Does an unsponsored agent in your tenant lose access automatically, or does it keep running until someone notices?

3. Register every new agent, Microsoft-native or third-party, through the same identity model before it touches production data. Can a third-party agent reach your enterprise APIs today without requesting a token through Entra first?

Phase 2: Lifecycle Enforcement at the Pipeline Level

4. Block any CI/CD deployment that lacks sponsor, purpose, and risk-tier metadata. Does your pipeline fail the build when that metadata is missing, or does it ship anyway?

5. Run a 30-day attestation cycle for every high-risk agent, owned by the sponsor, not the security team. Thirty days from now, who receives the notification asking whether Agent X still needs the access it has?

6. Set deny-all as the default scope for every new agent and whitelist only what the task requires. Does a newly provisioned agent in your environment start broad and get scoped down later, or start at nothing and earn access explicitly?

Phase 3: The Interception Layer

Moving past authentication means moving into the data path. Phase 3 shifts from identity configuration to active runtime traffic manipulation.

7. Route agent-to-tool traffic through a proxy instead of letting agents call APIs directly. Can any agent in your environment reach a production API right now without passing through an inspection point first?

8. Log the reasoning chain alongside every tool call, not just the call itself. If an agent deleted a record tomorrow, could you reconstruct why it decided to, or only that it happened?

9. Gate irreversible actions, large payments, production changes, bulk deletes, behind human approval before execution, not after. Does any agent in your environment currently have standing ability to execute an irreversible action with zero human checkpoint?

10. Baseline normal call volume per agent and pause the session automatically when behavior deviates from it. Would a sudden hundredfold spike in one agent’s API calls trigger anything in your environment right now, or would it run unnoticed?

The Interception Layer is not a configuration change. It’s an engineering build. Platform or security engineering typically owns it, not IT administration, and it’s worth treating as an initiative with a budget line, not a checkbox on a Conditional Access policy. The product category is starting to emerge commercially. Vendors are already building toward exactly this gap, but most organizations still build this in-house before they buy it off a shelf.

Not every fix maps to every risk one-to-one, and not every fix prevents what it touches. Some only limit the damage after the fact. Here’s where each control actually lands.

Three categories have no fix that fully prevents them: ASI04, ASI06, ASI08. Registering an agent’s identity doesn’t vet the third-party component it’s built on. Logging a reasoning chain tells you poisoning happened after it already shaped a decision. Baselining catches a cascading failure in progress, not before it starts. That’s not a weakness in this framework specifically. It’s the honest state of the field right now, and the same admission already applies to ASI07 above.

The Architecture Gap Is the Governance Story, Not the AI Story

Every organization racing to deploy Agent ID is solving a real problem. Anonymous, unattributed, unsponsored agents running in a tenant is a governance failure that predates AI by twenty years, and closing it matters.

It isn’t the same problem as a properly identified, properly sponsored agent making the wrong decision on its four hundredth action of the session, with a valid token and a clean Conditional Access record the entire time.

The Single-Login Fallacy is the assumption that identity governance and behavioral governance are the same control plane. They aren’t. Microsoft built one of them well. The other one is still wide open, and it’s the one that determines whether your agentic deployment is defensible or just well-labeled.

Nine governance mechanisms. Zero of them watching the part of the architecture most likely to cause your next incident.

If your organization is deploying agentic AI and your identity governance plan stops at sponsorship and Conditional Access, that’s exactly the gap The Single-Login Fallacy describes, and exactly the work this closes. Available for consulting engagements to assess runtime governance architecture for autonomous workloads before the gap becomes an incident. Connect on LinkedIn or reach out directly via LinkedIn DM.

About the Author

Albert Jee is an independent IAM consultant and former Microsoft FastTrack Architect with fifteen years of experience designing enterprise identity and access management solutions across healthcare, financial services, and Fortune 500 organizations. He specializes in Zero Trust architecture, Microsoft Entra ID, Conditional Access policy design, and cloud identity security.

He publishes technical thought leadership on Medium targeting CISOs and Staff/Senior IAM Architects navigating the gap between identity governance and runtime behavior. Available for consulting engagements to assess agentic AI deployments where identity-layer controls are in place but no architecture exists to govern what an agent decides to do once it has a valid token. Connect via LinkedIn or reach out directly via LinkedIn DM.