Your security team just finished rolling out Microsoft Agent 365. Agents have Entra identities, Purview is watching sensitive data, and Defender is flagging threats. Then the AI platform team mentions the claims agent running on another cloud, the coding assistant calling three model providers, and the open-source framework a product team shipped last quarter.
None of that changes the value of the Microsoft stack. It changes the question. The issue is no longer whether you have AI controls. It’s whether those controls reach every place AI actually runs.
This article walks through what the Microsoft AI governance stack covers, where enterprise AI estates usually extend beyond it, and how to carry the same policies across every model, agent, and cloud without building a second governance program.
What Microsoft Agent 365 governance covers
Microsoft Agent 365 is Microsoft’s control plane for observing, governing, and securing AI agents in an organization. It became generally available for commercial customers on May 1, 2026, licensed per user, and Microsoft notes it works best with Microsoft E5 as a prerequisite.
Agent 365 brings several Microsoft services together around agents:
- A central registry in the Microsoft 365 admin center that shows agent adoption, activity, and health.
- Microsoft Entra for identity and risk-based access controls on users and the agents acting for them.
- Microsoft Purview for information protection, data loss prevention, auditing, and insider risk.
- Microsoft Defender for threat detection and protection.
For organizations standardized on Microsoft 365, this is a strong foundation. It treats agents as managed identities rather than anonymous scripts, and it puts them under the same compliance tools that already govern users.
Where Purview DSPM for AI fits
Purview’s data security posture management gives security teams visibility into how AI interacts with sensitive data. For Agent 365, Microsoft’s Purview documentation points admins to the AI observability page in the current DSPM experience, and notes that the classic DSPM for AI does not support Agent 365.
The same documentation lists details worth planning around. Agent instances must be added to DLP and insider risk policies explicitly, much like a new user. Content that Agent 365 agents create does not inherit sensitivity labels from source files. And because an agent is not aware of a DLP block, Microsoft advises agent owners to monitor those policies so workflows don’t break silently.
Why enterprise AI estates outgrow one vendor’s controls
Most enterprises don’t run AI on one platform. They pick the best model for each task, inherit tools through acquisitions, and let product teams build with the frameworks they know. That creates three kinds of reach problems.
Models from more than one provider
A team might use Azure OpenAI for one workload, a different provider’s model for coding, and an open-weight model for a sensitive internal use case. Each provider has its own console, its own keys, and its own logs. Multi-model AI governance means applying one policy to all of them, not configuring three.
Agents built outside Microsoft tools
Microsoft says Agent 365 is designed to govern agents built with Microsoft tools, open-source frameworks, and partner platforms. In practice, coverage depends on how each agent is registered and connected. Agents that call models directly from another cloud, or that were built before anyone thought about registration, are the ones most likely to sit outside the registry.
Clouds and runtimes beyond Azure
Data residency, existing commitments, and team preference all put AI workloads on more than one cloud. Controls that live inside one cloud’s tenant can’t inspect a request that never touches it.
An architecture view: Microsoft as the foundation, extended across the estate
The practical answer is not to replace Microsoft controls. It’s to keep each Microsoft service doing what it does best, and add a layer that enforces policy wherever AI requests run.
| Layer | Microsoft service | What Airia adds |
|---|---|---|
| Identity | Microsoft Entra | Users sign in through Entra and are provisioned over SCIM, so every agent action carries a real identity. Airia also inventories third-party AI apps consented into the tenant, shows who approved each one, and lets admins revoke access |
| Data protection | Microsoft Purview | Existing Purview classifications carry over as governance classifications on connected data sources. At runtime, Airia inspects content in flight and can audit, block, or redact it, including sensitive content that was never labeled |
| Security operations | Microsoft Sentinel | Agent activity, policy violations, and audit events stream into Sentinel, so the SOC works from one place |
| Agent building | Copilot Studio and Microsoft Foundry | Airia is registered as Copilot Studio’s external threat detection provider, so its policy decides whether a tool call runs. It also discovers, inventories, and risk-classifies agents and models built in Foundry |
| Model access | Azure OpenAI and other providers | Requests route through Airia’s routing engine with policy enforcement and budget controls on every call, whichever provider serves them |
| Endpoints | Intune and Edge | Intune deploys Airia’s browser extension and endpoint agent to managed devices for AI discovery |
Read top to bottom, the pattern is consistent. Microsoft stays the system of identity, data classification, and security operations. Airia sits in the path of AI requests and applies those same decisions to models, agents, and clouds the Microsoft stack doesn’t see directly.
What this means for Copilot governance
Copilot governance is where many organizations start, and it’s a good place to be precise. Microsoft 365 Copilot is governed through Microsoft’s own controls, and those remain the right tools for it.
Copilot Studio is different. Business teams use it to build agents that call tools and connectors, which is where risk tends to concentrate. With Airia registered as Copilot Studio’s external threat detection provider, Copilot Studio checks with Airia before an agent calls a tool, and Airia’s guardrails decide whether the call runs. The same policies then apply to agents built anywhere else.
How to extend Microsoft AI controls without starting over
- Inventory first. Combine what Agent 365 and Entra already know with AI discovery across browsers and endpoints. Build the registry from what’s actually running, not only what was declared.
- Reuse Microsoft decisions. Keep Entra as the source of identity and Purview as the source of data classification. Don’t rebuild either in a second tool.
- Put enforcement in the request path. For models and agents outside Microsoft’s reach, apply guardrails, agent constraints, and model routing at the moment of the call.
- Send evidence home. Stream audit and violation events into Sentinel so security operations stays in one console, and use the governance dashboard for the AI program view.
- Use the commercial path you already have. Airia is transactable on Azure Marketplace, billed on the Azure invoice, and counts toward Microsoft spend commitments.
Questions to ask about your Microsoft AI governance coverage
- Which agents in production are not in the Agent 365 registry today?
- Which model providers do teams call directly, outside Azure?
- Does sensitive data protection apply to unlabeled content sent to a non-Microsoft model?
- Can security see agent activity from every cloud in Sentinel?
- If a team swaps the model behind an agent, does anyone find out?
If any answer is “we don’t know,” that’s the gap to close first.
A partner approach, not a replacement
Airia is built natively on Azure and is a Microsoft AI Cloud Partner, Microsoft Foundry AI Governance Partner, Digital Native Partner, and Microsoft ISV Success Partner. It integrates with ten Microsoft solutions, and it can run as shared SaaS or as a private deployment in your own Azure tenant when data cannot leave the boundary.
Anand Raman, GM Americas, AI GBB at Microsoft, describes the partnership this way: “Together with Airia, we are providing organizations a comprehensive control plane for Model Risk Management.”
The goal is simple. Your Microsoft investment stays at the center, and your AI governance reaches the rest of the enterprise AI platform estate you actually run. See the full set of integrations on the Airia and Microsoft partner page.
Conclusion
Microsoft Agent 365, Entra, Purview, and Defender give enterprises a strong base for governing AI inside the Microsoft estate. Most AI programs already reach past it. Keep Microsoft as the foundation, inventory what runs everywhere, enforce policy in the request path, and send the evidence back to the tools your security team already uses. That’s how one set of controls covers every model, agent, and cloud.
Map your AI estate against your Microsoft controls. Book a technical briefing to see where Agent 365, Entra, and Purview already cover you and where Airia extends them. Request a demo
Put these ideas to work.
Schedule a 30-minute walkthrough with our team.