Why Agentic AI Requires Entra, Purview, Defender, and Real Governance Before It Scales

When AI Can Act, Policy Stops Being Optional

This article is part of the EPC Group Microsoft Build 2026 series. For the full strategic read on Project Solara, the Copilot Super App tease, MAI, Scout, MDASH, and RTX Spark — see the pillar: Project Solara, the Death of Apps, and the One Copilot That Wasn't.

There is a governance principle I have been saying in boardrooms for years that used to sound theoretical. It doesn't anymore: the more capability you hand a system, the more disciplined the control architecture around it must be.

For a long time, AI in the enterprise was largely a read operation. A language model consumes context and produces text. You review the output and choose whether to act. The policy question was: what data can the model see? That's a meaningful question, and most organizations haven't fully answered it. But it's manageable. The model doesn't call your procurement system. It doesn't send email on your behalf. It doesn't book the meeting, escalate the ticket, or modify the record.

Agentic AI changes every one of those sentences. And Microsoft Build 2026 did not slow capability deployment while enterprises caught up on governance. The agents are shipping. The capabilities are real. The question before every CIO and CISO this week is whether the control plane around them is real too.

This article is about that control plane — and about the specific components, some pre-Build and some announced at Build itself, that enterprises need to understand, configure, and build policy around before their agent deployments reach production scale.

---

The Identity Foundation: Every Agent Needs an Entra Principal

The first and most fundamental governance requirement for agentic AI is identity. An agent operating without a traceable principal in your directory is a policy blind spot. It is the digital equivalent of a contractor working in your building with no badge, no access log, and no termination procedure.

Microsoft built this correctly into the Scout Autopilot architecture. Each Autopilot instance is bound to its own Entra identity for attribution. That design choice matters more than almost anything else in Scout's feature list. When Scout preps a meeting brief, blocks focus time, or surfaces a stalled decision, that action is attributed to a named principal in your directory. You can scope it. You can audit it. You can revoke it.

That should be the architectural requirement for every agent you deploy — not just Microsoft's. If you are evaluating a third-party agent, a custom-built workflow, or a departmental AI automation and it does not carry a bounded Entra identity with defined permission scope, it should not operate in a production tenant.

The governance failure mode here is what I call permission sprawl at the agent layer. In traditional IAM, sprawl accumulates over years as employees change roles without cleanup. At the agent layer, the accumulation rate is dramatically higher. Ten agents in thirty days, each with broadly scoped permissions, and you have no coherent picture of what your collective agent estate can touch across your M365 environment. That is not a hypothetical scenario. That is what happens when organizations adopt agent capabilities without an identity governance framework that treats agents as first-class principals.

---

Agent 365: The Control Plane That Was Already GA

Here I need to make an important clarification that most of the Build coverage got wrong.

Agent 365 — Microsoft's unified control plane for observing, governing, and securing agents — went generally available on May 1, 2026, before Build. It is not a Build announcement. What Microsoft announced at Build is the Agent 365 SDK, which is the Build 2026 item. The MXC integration (Defender/Entra/Intune/Purview delivery) ships in July.

This distinction matters because it changes the deployment conversation. Agent 365 as a management and governance control plane is available to you right now. The agent registry, the visual map of your agent estate, the surfacing of unmanaged local agents — that capability exists today. Organizations waiting for a future governance platform have been waiting unnecessarily.

What Agent 365 provides is visibility and governance over your entire agent estate: every registered agent, its identity, its access scope, its activity. The SDK announced at Build extends that control plane to developers building custom agents, giving them the same governance hooks. And the deeper integration with MXC containment — the layer that enforces execution boundaries at the OS level — arrives in July.

If you have not yet deployed Agent 365, you are running agents in your environment without a control tower. That is a risk posture, not a strategy.

---

The Open Trust Stack: ACS and ASSERT

This is the part of Build 2026's governance story that received the least mainstream coverage and deserves the most enterprise attention.

Microsoft announced what they are calling an "open trust stack" for agents, built on two open-source components: the Agent Control Specification (ACS) and ASSERT.

ACS: Deterministic Allow/Deny at Every Stage

ACS — the Agent Control Specification — is an open standard that gives any agent runtime a deterministic allow/deny decision at five lifecycle checkpoints: input, LLM, state, tool execution, and output. Not probabilistic guardrails. Not "the model was instructed not to do this." A structural enforcement mechanism at each stage of the agent execution lifecycle.

The distinction between probabilistic instruction and deterministic enforcement is the entire game in agentic governance. Telling a model "don't share sensitive data" is a soft constraint — it is subject to prompt injection, model drift, context window manipulation, and adversarial inputs. ACS at the tool execution checkpoint means the agent literally cannot invoke a tool that violates the declared policy, regardless of what the model's output contains. The enforcement is structural, not instructional.

For enterprise governance, ACS translates the principle of least privilege from a policy document into a runtime enforcement mechanism. Your governance team declares the policy in plain terms. ACS enforces it deterministically across every agent execution, on any runtime that implements the standard — whether that's a Microsoft agent, a LangChain workflow, or a custom Foundry deployment.

ASSERT: Regression Testing for Agent Behavior

ASSERT — Adaptive Spec-driven Scoring for Evaluation and Regression Testing — is an open-source (MIT-licensed) evaluation and regression framework from Microsoft Research. It converts plain-text behavioral specifications into executable test suites. Works across LangChain, CrewAI, LiteLLM, OpenAI, and other common frameworks.

What ASSERT addresses is the test gap in enterprise AI deployments. Organizations building agentic workflows typically have no formal way to verify that agent behavior continues to conform to policy as models are updated, prompts evolve, or integration surfaces change. ASSERT closes that gap: your compliance team writes behavioral requirements in plain language, and ASSERT converts those requirements into tests that run as part of your CI/CD pipeline.

Think of it as unit testing for governance. The moment a model update, a new tool integration, or a changed prompt causes agent behavior to deviate from your policy specification, ASSERT catches it before it reaches production.

Together, ACS and ASSERT constitute something genuinely new: a testable, enforceable, open-standard governance layer for agentic systems that doesn't depend on trusting any individual model to behave correctly. ACS enforces. ASSERT verifies. The model is one input. The controlled system is the product.

That last framing came from Taesoo Kim, VP of Agentic Security at Microsoft, describing MDASH — and it applies equally to the open trust stack. The organizations that will govern agentic AI effectively are not the ones with the most restrictive prompt engineering. They are the ones with the most disciplined execution architecture.

---

The Data Protection Layer: Purview Finds What You Didn't Know Was Exposed

If Entra is the identity layer for agents, Purview is the data protection layer — and the relationship between Purview and agentic AI is one of the most consequential architectural conversations enterprises need to have right now.

Bluntly: AI doesn't create data governance problems. It finds them. Accelerates them. And in the agentic era, acts on them.

Every organization I have worked with over the past several years carries some version of the same underlying condition. Sensitivity labels applied inconsistently. Documents with "Confidential" in the filename living in SharePoint sites with broad external sharing enabled. Historical content that no one has reviewed in three years because no one had a business reason to surface it. DLP policies covering email but not extended to Teams or SharePoint channels.

When agents start reasoning over your data estate — not just reading it, but grounding outputs in it and taking autonomous actions based on what they find — every one of those conditions becomes an active exposure rather than a latent one. Purview labels, DLP policies, and audit trails are not compliance theater in an agentic environment. They are the mechanism by which you know what your agents saw, what they were permitted to access, and whether that access was appropriate.

Work IQ uses permission-aware governance and logs every tool invocation through its Rego-based policy engine. That is excellent architecture. But permission-aware enforcement is only as meaningful as the underlying permissions themselves. Purview's value in an agentic deployment is ensuring the labels, policies, and access controls the governance layer enforces reflect your organization's actual intent — not the accumulated residue of seven years of undisciplined SharePoint provisioning.

Before you expand your agent deployment, your Purview posture needs to answer three questions cleanly: Are sensitivity labels applied to the content that actually needs them? Do your DLP policies cover every channel agents operate in, not just the channels humans traditionally used? Can your audit logs reconstruct what an agent accessed, why, and what it produced in response?

If the answer to any of those is "not really," you have a Purview gap that agent deployment will make visible in the most uncomfortable way possible.

---

MXC Containment: Execution Boundaries Arriving in July

The Microsoft Execution Containers (MXC) SDK is a cross-platform, policy-driven execution layer for agents across Windows and WSL. The concept is architecturally elegant: when you declare an agent, you declare what it can access — files, network resources, system capabilities — and containment is enforced at runtime. The agent cannot exceed its declared scope, not because it chooses not to, but because the execution environment prevents it.

OpenClaw, the engine that powers Scout, already runs natively on Windows leveraging MXC as open source. Windows 365 for Agents — secure managed Cloud PCs for computer-using agents — is GA within Agent 365 today, extending containment beyond the local device.

The fuller integration — Agent 365 delivering Defender, Entra, Intune, and Purview protections through MXC — ships in July. That is a near-term delivery, not a roadmap aspiration. Organizations deploying agents now should be planning their MXC and Agent 365 integration work so they are operationally ready when that integration lands, rather than treating it as a future governance item.

For security architects, the right question to be asking today is: have we declared what every agent in our estate is permitted to access, and is that declaration enforced at the execution layer or only at the policy document layer? ACS handles the lifecycle checkpoint enforcement. MXC handles the OS-level execution boundary. Together, they close the gap between governance intent and governance reality.

---

MDASH: Why the Disciplined System Beats the Brilliant Model

The proof case for the entire governance architecture I've described — identity, ACS enforcement, ASSERT testing, Purview data protection, MXC containment — is MDASH.

MDASH — Microsoft's multi-model agentic scanning harness — is a 100-plus agent system that achieved 96.55% accuracy on the CyberGym benchmark (UC Berkeley, 1,507 real vulnerability reproduction tasks, 188 open-source projects) and identified 16 previously unknown Windows vulnerabilities, including 4 Critical, in May 2026. It improved approximately 10 percentage points in less than three weeks.

The architecture: five-stage pipeline — Prepare, Scan (auditor agents), Validate (debater agents), Dedup, Prove (constructs and executes real triggering input). The validation stage is the key governance design insight: debater agents review auditor outputs, and "disagreement between models is treated as a confidence signal rather than a noise event." No single agent is the final authority. The system uses structured disagreement to produce reliable conclusions.

MDASH now integrates natively into the Defender Portal via GitHub Code Security — the renamed successor to GitHub Advanced Security — with Copilot Autofix.

This is the blueprint. Not one omniscient agent with broad permissions and high confidence. A governed ensemble with bounded scope, structured validation, and a control plane that treats model disagreement as data rather than failure. Taesoo Kim's formulation — "the model is one input, the system is the product" — describes every production-grade agentic deployment that will actually hold up under audit, under incident, and under the adversarial conditions that real enterprise environments produce.

---

Moving from Acceptable Use to Controlled Execution

Most organizations approaching AI governance today are at the acceptable use policy layer. They've published a document governing what employees may and may not do with AI tools. Some have added data classification requirements for AI inputs. That is necessary. It is nowhere near sufficient for an agentic environment.

The precise distinction: acceptable use policy governs human choice. Controlled execution governance governs what systems are architecturally permitted to do, independent of human choice. When the system is the actor — when Scout schedules the meeting, queues the email, surfaces the document without being asked — policy that only constrains human behavior provides no protection.

Controlled execution governance means: every agent carries a scoped Entra identity. ACS enforces allow/deny decisions at each lifecycle checkpoint. ASSERT validates behavioral conformance continuously as models and integrations change. Purview coverage extends to every channel agents operate in. MXC (in July) enforces execution boundaries at the OS layer. Agent 365 provides the control tower with visibility across the full agent estate. Approval gates define which action categories require human confirmation before execution.

That is the architecture. It requires sequencing, expertise, and real organizational commitment to implement correctly. The alternative is deploying powerful autonomous agents on top of whatever governance posture you have today and discovering the gaps through incidents rather than audits.

---

What EPC Group Does Here

Our Microsoft AI Security and Governance Review is built for exactly this inflection point. We assess your Entra identity model for agent readiness, evaluate Purview labeling and DLP coverage against the channels your agents actually use, review your Agent 365 deployment and configuration, and map ACS and ASSERT implementation against your planned agent workflows.

The output is a prioritized remediation roadmap that sequences foundation work against your agent deployment timeline — so governance architecture keeps pace with capability deployment rather than trailing it by eighteen months and surfacing through a compliance incident.

We also provide Virtual Chief AI Officer (vCAIO) support for organizations that need executive-level AI governance strategy without a dedicated hire, and our 30-Day Copilot/Purview/M365 Tenant Hardening Accelerator compresses the foundational work into a structured, outcomes-based engagement.

The agents are running. Agent 365 has been GA since May 1st. The open trust stack — ACS and ASSERT — is available today. The only question is whether your governance architecture is running as fast as your AI capability deployment. In most organizations I talk to, it isn't. That is the conversation worth having before the incident that makes it unavoidable.

---

FAQ

Agent 365 was announced at Build — is it new?
Agent 365 went GA on May 1, 2026, before Build. What Microsoft announced at Build 2026 is the Agent 365 SDK, which extends the control plane to custom agent development. The Defender/Entra/Intune/Purview integration via MXC ships in July.

What is ACS and why does it matter for enterprise AI governance?
The Agent Control Specification is an open standard that enforces deterministic allow/deny decisions at five agent lifecycle checkpoints: input, LLM, state, tool execution, and output. Unlike instructional guardrails (telling the model what not to do), ACS provides structural enforcement that the model cannot override. It is compatible with any runtime that implements the standard.

What is ASSERT and how does it work in practice?
ASSERT — Adaptive Spec-driven Scoring for Evaluation and Regression Testing — is an open-source (MIT) framework from Microsoft Research that converts plain-text behavioral specifications into executable test suites. Your compliance or governance team writes behavioral requirements in plain language; ASSERT runs those as automated tests across your agent stack (LangChain, CrewAI, LiteLLM, OpenAI, etc.) so any deviation from policy is caught before production.

When does MXC's full integration with Agent 365 ship?
The Agent 365 native integration with MXC — which delivers Defender, Entra, Intune, and Purview protections through the execution containment layer — ships in July 2026. MXC itself is already available in early preview; OpenClaw (Scout's engine) already runs on Windows via MXC.

What's the difference between acceptable use policy and controlled execution governance?
Acceptable use policy governs human choice. Controlled execution governance governs what systems are architecturally permitted to do, independent of human choice. In an agentic environment where systems act autonomously, only the latter provides meaningful protection.

---

Sources

• Work IQ: Production-Ready Intelligence for Every Agent — Microsoft 365 Dev Blog
• No Longer Just a Copilot: Microsoft's AI Wants to Take the Wheel — The Register
• Build 2026: Furthering Windows as the Trusted Platform for Development — Windows Dev Blog
• MDASH Gains Defender Integration at Build 2026: 96.55% CyberGym Benchmark — TechTimes
• Microsoft Build 2026: Biggest Announcements — The Verge
• Microsoft Build 2026 Recap — PCMag
• Microsoft Build 2026: Agent-First Future — Mashable
• Is Microsoft AI the Ultimate Enterprise Trojan Horse? — AI Magazine

---

EPC Group · contact@epcgroup.net · 888-381-9725 · www.epcgroup.net

---

---

EPC Group Can Help

Microsoft Build 2026 raised the ceiling on what agentic AI can do across the Microsoft estate — and the floor on what your tenant has to be to deploy it safely. EPC Group has been doing this work for 29 years across Fortune 500 and federal organizations, with six Microsoft Solutions Partner designations and a perfect 100 NPS on G2.

If any of the following sound like your next 90 days, that is exactly the work we do:

• Microsoft 365 Copilot Readiness Assessment — the 30-day tenant audit, Purview labeling, and adoption motion that turns an under-5% Copilot conversion into a measured rollout.
• Governed AI on Microsoft Framework — one named architecture covering Entra, Purview, M365, SharePoint, Fabric, Power BI, Copilot, Defender, and Agent 365. Seven layers, five maturity stages, one accountable owner.
• Virtual Chief AI Officer (vCAIO) — fractional senior leadership for organizations that need the operating model in 2026 but cannot hire a full-time AI executive yet.
• AI Consulting Services, AI Governance, Microsoft Copilot Consulting, Power BI Consulting, Microsoft Fabric Consulting, and Azure Consulting.

Email contact@epcgroup.net, call 888-381-9725, or request a consultation. Senior architects only — no offshore handoff, no junior account managers.

LinkedIn Post

THE MODEL IS NOT THE RISK. THE UNGOVERNED SYSTEM IS.

Taesoo Kim, VP of Agentic Security at Microsoft, said that while describing MDASH at Build 2026. It's the most important sentence from the entire conference — because it defines exactly where enterprise AI deployments break over the next 18 months.

Most coverage of Build focused on the capabilities. I want to focus on the governance architecture — because Microsoft actually shipped something significant here that almost nobody talked about.

WHAT MOST COVERAGE MISSED

Agent 365 went GA on May 1st. Not at Build. Before Build. The unified control plane for observing, governing, and securing your entire agent estate — registry, visual map, unmanaged agent surfacing — has been available for a month. Organizations waiting for a governance platform to arrive have been waiting unnecessarily.

What shipped at Build is the Agent 365 SDK — the developer extension that brings the same governance hooks to custom-built agents. And the deeper MXC integration (Defender/Entra/Intune/Purview through OS-level containment) ships July. Plan for it now.

THE OPEN TRUST STACK: ACS + ASSERT

Here's the genuinely new governance architecture from Build that deserves every enterprise architect's attention.

Microsoft announced two open-source components that together form what they call an "open trust stack" for agents:

ACS — the Agent Control Specification. An open standard that gives any agent runtime deterministic allow/deny decisions at five lifecycle checkpoints: input, LLM, state, tool execution, and output.

This is not "tell the model not to do something." This is structural enforcement. The agent cannot invoke a tool that violates your declared policy regardless of what the model outputs. Prompt injection doesn't override it. Model drift doesn't override it. The enforcement is architectural, not instructional.

ASSERT — Adaptive Spec-driven Scoring for Evaluation and Regression Testing. Open source, MIT license, from Microsoft Research. Your compliance team writes behavioral requirements in plain text. ASSERT converts them into executable test suites that run across LangChain, CrewAI, LiteLLM, OpenAI, and other frameworks.

Think of it as governance regression testing. Every model update, every new tool integration, every prompt change — ASSERT verifies that your agents still behave according to your policy specification. Behavioral drift becomes detectable before it becomes an incident.

ACS enforces. ASSERT verifies. The model is one input. The controlled system is the product.

FROM ACCEPTABLE USE TO CONTROLLED EXECUTION

Most organizations today are operating at the acceptable use policy layer. A document. Some guidelines. Maybe data classification requirements.

That governs human choice. In an agentic environment, the system is the actor. Scout books the meeting. The agent queues the email. The automation files the ticket. Policy that only constrains what humans choose to do provides zero protection from what autonomous systems are permitted to do.

Controlled execution governance is different. Every agent has a scoped Entra identity. ACS enforces at every lifecycle checkpoint. ASSERT validates continuously. Purview covers every channel agents touch. MXC enforces OS-level execution boundaries in July. Agent 365 gives you the control tower.

THE MDASH PROOF CASE

96.55% on CyberGym. 16 unknown Windows vulnerabilities found in May, including 4 Critical. A 100+ agent ensemble where debater agents review auditor outputs and disagreement is treated as a confidence signal.

That's what disciplined multi-agent architecture looks like at scale. Not one model with high confidence and broad access. A governed system with structured validation, bounded scope, and a control plane that coordinates the ensemble.

Every enterprise agent deployment should be designed against that standard.

WHAT TO DO THIS WEEK

Deploy Agent 365 if you haven't. It's GA. Evaluate ACS for your agent runtimes. Start writing behavioral specs that ASSERT can test. Audit your Purview coverage for the channels agents actually use. Plan MXC integration for July.

At EPC Group, our Microsoft AI Security and Governance Review sequences this work against your deployment timeline — so governance keeps pace with capability.

What's the hardest governance gap to close in your current AI deployment? Drop it below — it's almost certainly where ACS or ASSERT adds the most immediate value.

#AgenticAI #MicrosoftBuild2026 #AIGovernance #ACS #ASSERT #Agent365 #MicrosoftEntra #Purview #Defender #EPCGroup #EnterpriseAI #OpenTrustStack

---

X Post

Microsoft's open trust stack from Build 2026 is being underreported.

ACS: deterministic allow/deny at 5 agent lifecycle checkpoints. Not a guardrail — structural enforcement.

ASSERT (MIT): converts plain-text policy specs into regression tests for agent behavior.

Agent 365 was GA May 1. MXC integration ships July.

The model is one input. The governed system is the product. https://www.epcgroup.net/agentic-ai-governance-entra-purview-defender/ #MicrosoftBuild2026 #AIGovernance