Where every piece of AI your people actually touch sits in the estate, and which Microsoft control covers it. Entra capabilities are called out separately, because they do more of this than most architectures give them credit for.
Last verified: September 22, 2026. Preview and GA status move quickly here, so check the docs before you design against this.
Scroll sideways on a narrow screen.
Five columns, left to right. The devices your people use. The network layer everything should route through. The four kinds of AI they actually touch. What protects and detects. And where it all lands for whoever runs your SOC.
The two amber boxes are the honest parts. Consumer AI opened in a browser creates no identity and registers nothing, so every control built around agent identity has nothing to attach to. A locally installed agent skips the network layer completely, which is why the endpoint is the only place it turns up. Most versions of this diagram leave both of those out.
Windows, macOS, mobile, and whatever people bring from home. The thing to notice here is that two very different populations live in this box. Managed devices you can route, inspect and put an agent on, and everything else.
The BYOD box is dashed rather than excluded, because the boundary is softer than people assume. Purview data security controls reach Edge for Business on unmanaged Windows and macOS devices provided the user is signed into their Edge for Business profile, and that works without Endpoint DLP on the device. The network layer is stricter: if traffic is not routing through Global Secure Access, Internet Access controls do not apply. So the real line is the sign in, not the device.
Everything egressing a managed device should pass through Entra Global Secure Access. Three capabilities sit here and they do different jobs.
Internet Access is the one that has changed most. It now works as a secure web and AI gateway. It discovers unsanctioned private apps, shadow IT, generative AI and SaaS alongside Defender, protects against prompt injection at the network layer, and stops data exfiltration by integrating network filtering with Purview classification policies. On this diagram it is the only control that reaches the consumer AI box, because it does not need anything to have been registered first.
Private Access handles the other direction: agents and users reaching internal applications, segmented per application rather than trusted at network level. If you have been running a VPN for this, it replaces it.
Conditional Access decides who gets through at all, and once agents hold identities it applies to them exactly as it applies to people.
M365 Copilot and Security Copilot sit inside your tenant, so Purview sees prompts and responses natively and the data stays governed by the controls you already run.
The consumer row underneath is the interesting one. Purview DSPM for AI sorts AI apps into three groups: Copilot experiences and agents, enterprise AI apps such as Foundry, Entra registered AI apps, Anthropic Claude Enterprise and ChatGPT Enterprise, and then other AI apps, meaning consumer ChatGPT, Gemini, consumer Copilot and DeepSeek. Microsoft is upfront that the third group is the hardest to manage because people reach it straight from a browser.
Two things cover it. Purview, through its browser extension for Edge, Chrome and Firefox plus Endpoint DLP, which can warn or block someone entering sensitive information into a third party AI site. And Internet Access at the network. They are complementary: Purview knows your data and enforces in the browser, Internet Access knows the traffic and enforces at egress.
Behind both sits Defender for Cloud Apps. Its cloud app catalog has a generative AI category with more than a thousand apps, each with a risk score. Internet Access shadow AI discovery matches traffic against that catalog, and Defender for Endpoint feeds it cloud discovery from the device. Tag an app unsanctioned and it can be blocked, and discovery policies can unsanction new AI apps automatically by risk score or user count. This is where the decision about which consumer AI is allowed gets made. Purview and Internet Access then enforce it.
Copilot Studio agents, agents inside Microsoft 365, Security Copilot agents, and third party SaaS agents from platforms your business already runs.
Every one of these should hold an Entra Agent ID principal. That is what makes the rest of the column work, because once an agent is a directory identity it inherits Conditional Access, entitlement management, access reviews and lifecycle just like any other principal.
The detail worth carrying around: agent identities hold no credentials of their own. They authenticate through a blueprint, and permissions granted to a blueprint reach every agent created from it. So the blueprint is the object worth inventorying and protecting, not the individual agent.
Copilot Studio agents also get runtime protection from Defender, a capability that first shipped in Defender for Cloud Apps. It checks tool calls before they run and blocks risky ones, and records each block as a behavior you can hunt on.
Agents running in Microsoft Foundry, Container Apps, App Service or Functions. Foundry does the Entra Agent ID work for you: the first agent in a project gets a default blueprint and agent identity, and publishing an agent creates a dedicated blueprint and identity bound to it. App Service and Functions can use the agent identity platform too. Container Apps and anything custom go the managed identity or sidecar route.
The Foundry detail that catches people out: until an agent is published, every agent in the project shares one identity. Whatever you grant that shared identity, every agent in development gets. So check what the project identity holds before you trust the per agent picture in the directory.
Publishing also puts the agent in the Agent 365 registry. Every published Foundry agent, prompt or hosted, syncs into it automatically, so Agent 365 is the one inventory that holds Foundry, Copilot Studio and shadow agents together. Two conditions sit behind that. Nothing flows until the tenant has Agent 365 enabled and its terms accepted, whatever the Foundry resource setting says. And activity data from hosted agents needs the Agent 365 SDK in the agent plus Entra permissions for the Agent 365 observability service. Prompt agents send it without that work.
Hosted agents can also become autopilots. An autopilot acts as itself, not on behalf of a user, because it gets an Entra agent user account on top of its agent identity. After publishing and admin approval its blueprint appears in the Agent 365 registry and people hire instances of it in Teams. Treat those as user shaped identities: they are what the Conditional Access policies for agent users are for.
One residency point for the privacy team. Foundry keeps data in the Azure region of the resource, Agent 365 stores it in the tenant's geography. Syncing moves agent activity data from one to the other. You can opt individual Foundry resources out.
The third is Defender for Cloud, which covers posture for the agent and what it runs on, including recommendations specific to Foundry agents, such as flagging an agent exposed to indirect prompt injection whose MCP tool actions do not need human approval. Purview picks up prompts and responses once it is enabled on the Azure subscription, covered under cloud LLMs below because the same condition applies.
Agents hosted outside Azure, or on premises, can still hold a governed Entra identity. Two patterns exist. The Entra ID Auth SDK runs as a sidecar container alongside the agent, which works for containerised agents and local models including Ollama with LangChain. Or workload identity federation exchanges credentials from an external identity provider directly for Entra tokens, skipping the sidecar.
Both are real, and both are per agent or per platform engineering work. Neither is discovery. If anyone is planning on the assumption that agents built elsewhere will simply appear under governance, that does not happen.
Azure OpenAI and the other Foundry models. It is tempting to draw a line from here to Entra Agent ID, and it would be wrong. A model deployment is a resource that identities call. It is not an agent and it does not get an agent identity. The identity work here is on the caller side: callers use Entra auth with managed identities, and you turn key based access off so nothing is holding a key that works from anywhere.
Three controls do the actual work.
Defender for AI Services, the AI threat protection plan in Defender for Cloud. It raises runtime alerts for jailbreak attempts, credential leakage in model responses, ASCII smuggling, phishing URLs, wallet attacks and anomalous tool calls, and those alerts go to Defender XDR. It covers Azure OpenAI and Foundry model inference, text tokens only, in commercial clouds only. Prompt evidence in alerts is a separate toggle. If you leave it off, detection still runs but the SOC sees masked prompts.
Content Safety Prompt Shields, with an AI gateway in front. Prompt Shields blocks or flags direct and indirect prompt injection at the model. The API Management AI gateway puts a single policy point in front of every model deployment: content safety checks, per consumer token limits, and managed identity to the backend. If more than one team or app calls your models, this is where you enforce anything consistently.
Purview, through the Foundry integration. Enable it on the subscription and prompts and responses land in Audit and DSPM for AI as enterprise AI app interactions. The caveat that decides whether this is a control or just a log: Purview data security policies only enforce on calls that carry a user context token. An app calling the model with its own managed identity gets audit and classification, not enforcement. Most agent traffic is the second kind.
| Control | What it does here |
|---|---|
| Purview | DSPM for AI reporting, browser extension, Endpoint DLP, Insider Risk Management and Adaptive Protection. On the consumer AI path this is your primary control, not a supporting one. On Foundry it audits everything but only enforces on calls that carry user context |
| Agent 365 | Registry and control plane. Knows what has been published, across Microsoft 365, third party and Foundry agents (every published Foundry agent syncs in), plus runtime observability |
| Entra Agent ID | A directory principal per agent. Created automatically for Foundry and, when enabled, Copilot Studio agents. Agents from elsewhere come in by sidecar or federation. Not for models, which are resources rather than principals |
| Entra ID Governance | Every agent identity and blueprint needs a human sponsor, and sponsorship passes to the sponsor's manager automatically if they leave. Access comes through access packages that expire, with the sponsor notified to renew or let it lapse. Access reviews and Lifecycle Workflows cover the rest |
| Entra ID Protection | A Risky Agents report with agent specific detections such as unfamiliar resource access and sign in spikes. Agent risk is a Conditional Access condition, so a high risk agent can be blocked automatically. Learning mode suppresses behavioural detections until a new agent has a history, so expect a quiet first few weeks. Needs P2 in preview, and Microsoft says an Agent 365 licence will be needed soon |
| Defender for Cloud | AI security posture for anything you host yourself, plus Defender for AI Services runtime alerts on model deployments: jailbreak, credential leakage, wallet attacks, anomalous tool calls. Alerts go to Defender XDR |
| Content Safety and AI gateway | Prompt Shields at the model, and API Management AI gateway policies for content safety and token limits across every caller. Prevention, where Defender for AI is detection |
| Defender for Cloud Apps | Generative AI app catalog with risk scores, sanction and block, and discovery policies. It is the catalog behind shadow AI discovery in Internet Access |
| Defender for Endpoint | Finds local agents and shadow AI on the device. On this diagram it is the only thing that reaches a locally installed agent |
Sentinel for correlation, hunting and retention. Defender XDR for incidents, investigation and automated response. Worth checking the connector position for each source above rather than assuming everything lands, because that is where these architectures usually leak.
Pulled out on its own, because this is the part most AI security architectures under use.
| Capability | Covers |
|---|---|
| Internet Access | All outbound AI traffic, including consumer services nobody registered |
| Private Access | Agents and users reaching internal applications, segmented per app |
| Conditional Access | Which users and which agent principals get through. For agents the only grant is block, since they cannot do MFA |
| Agent ID | A directory principal per agent, Microsoft built or not |
| ID Governance | Sponsors, access packages that expire, access reviews and Lifecycle Workflows for agents |
| ID Protection | Risky agent detections, fed into Conditional Access as agent risk |
| Workload identities | Managed identities and federated credentials for whatever calls your models, so nothing holds a secret |
If you bought Microsoft 365 E7, Entra Suite came with it. In most tenants I look at, none of this has been switched on, which is not negligence so much as what happens when capability arrives inside a purchase justified on something else.
Most enterprise versions of this diagram have non Microsoft products in several boxes. If you are working out whether the Microsoft stack covers the same ground, this is roughly the mapping.
| Commonly sits here | Microsoft equivalent | Worth knowing |
|---|---|---|
| CASB for SaaS and AI app discovery | Defender for Cloud Apps | Generative AI category in the app catalog, with risk scores and sanction or block. Shares its catalog with Internet Access shadow AI discovery |
| SWG or SSE for internet egress | Entra Internet Access | Now a secure web and AI gateway, with shadow AI discovery and prompt injection controls at the network layer |
| ZTNA for private apps | Entra Private Access | Per application segmentation rather than network level trust |
| CNAPP for AI workload posture | Defender for Cloud | AI workload posture and model exposure. Check coverage against your actual clouds before assuming parity |
| Third party SIEM or SOAR | Microsoft Sentinel and Defender XDR | Sentinel for correlation and retention, Defender XDR for incidents and response |
| LLM gateway or proxy | Azure API Management AI gateway | Token limits, content safety checks and managed identity to the backend, for Foundry models and other providers. Can be attached from inside Foundry |
| AI runtime protection or LLM firewall | Defender for AI Services and Content Safety Prompt Shields | Prompt Shields prevents, Defender for AI detects and alerts. Azure hosted models only, text only |
| Standalone DLP for AI | Purview DSPM for AI | Browser extension covers Edge, Chrome and Firefox. One click policies get you to a working control quickly |
Parity on a diagram is not parity in a tenant. Every one of these swaps has edges: which clouds, which browsers, which device join states, and what is preview rather than GA. Test your own combination before committing to a consolidation.
No agent identity, nothing registered, so the agent governance stack has nothing to work with. The control point moves to the user. Purview at the browser and endpoint, Internet Access at the network, Conditional Access deciding who reaches sanctioned services at all.
One limit to know, both for expectations and for the privacy conversation you will inevitably have: the Purview browser extension logs metadata such as site, timestamp, user and matched policy. Not prompt or response text. DSPM for AI reports on policy matches, not on what people typed.
A local agent someone brought in deliberately can hold a governed identity through the sidecar or federation patterns above. A local agent nobody brought in holds nothing, appears in no registry, and shows up only on the endpoint. That is why reconciling Defender for Endpoint against the registry and against Entra is worth an afternoon.
And a genuinely local agent with no network egress, running against local files for one person, touches none of this. No traffic to inspect, no identity, no telemetry. That is a legitimate architecture and it sits outside everything on this page. Better to say so than pretend otherwise.
Ask Microsoft how many agents you have and each screen gives a different answer, because each one counts a different thing.
| Screen | What it counts | Where it goes wrong |
|---|---|---|
| Agent 365 registry | Agents available to the tenant | Overcounts. It lists third party and Microsoft out of the box agents that have not been installed or used anywhere, plus Power Platform and Dynamics 365 entries. Foundry agents appear only once published and Agent 365 is enabled |
| Entra Agent ID | Directory principals | Counts agents before they exist in any meaningful sense. A Copilot Studio agent I built and never published showed up straight away, because it sits under the shared Copilot Studio blueprint. It also misses classic Copilot Studio agents on ordinary app registrations, and unpublished Foundry agents share one project identity |
| Security Dashboard for AI | Agents with activity and risk signals | Undercounts new work. The same unpublished agent did not appear, because it had not done anything yet |
Defender AgentsInfo | What security tooling can see | Depends on licence (below). The only view that includes agents on laptops |
| Defender for Cloud Apps | Generative AI apps | Counts apps, not agents. A different question |
So one unpublished agent can be in Entra, missing from the dashboard and missing from the registry, all at once, and every screen is correct about what it measures.
Licensing then decides which of those views you can see at all. The registry and Entra agent identities are visible on base Microsoft 365 plans and any Entra tier. AgentsInfo is split. Local agents appear with Defender for Endpoint P2. Everything else, meaning Copilot Studio, Foundry and partner agents, appears only with Agent 365. So an E5 tenant without Agent 365 sees only laptop agents in AgentsInfo. It holds three partial inventories and no complete one, and switching Agent 365 on makes the numbers jump without a single new agent being built.
Never quote an agent count without naming the screen and the licence behind it. How to reconcile them is on the Agent Map page.
Being entitled to a capability tells you what you are allowed to use. It tells you nothing about whether it is deployed, configured, or covering the agents you think it covers. Those two claims come apart somewhere between the engineering team and the risk committee.