Microsoft Build 2026: Inside the Open Agent Trust Stack

At Build 2026 in San Francisco (June 2-3), Microsoft shipped the most complete attempt yet at a governed agent runtime: an open trust stack with four layers - identity, isolation, control checkpoints, and evaluation - that lets an enterprise run AI agents the way it already runs people and machines (Source: Microsoft Foundry blog). The pieces are Entra Agent ID for who an agent is, MXC for where it runs, the Agent Control Specification for what it is allowed to do, and ASSERT for whether the controls held. This guide maps the four layers, the open-source repos behind each, and how to decide what to pilot now.

Key takeaways

  • Identity: Windows assigns each agent a local ID or an Entra-backed cloud identity, so every action is attributable to a known actor instead of a shared service account (Source: Windows Developer blog).
  • Isolation: MXC (Microsoft Execution Containers) is a policy-driven, kernel-enforced sandbox layer with a spectrum from process isolation to micro-VMs. Early preview; repo at github.com/microsoft/mxc (Source: Windows platform security blog).
  • Control: the Agent Control Specification defines five validation checkpoints (input, LLM, state, tool execution, output) as portable policy YAML. Repo at github.com/microsoft/agent-governance-toolkit (Source: Microsoft Foundry blog).
  • Evaluation: ASSERT is an open-source, policy-driven evaluation framework that turns written policies into measurable tests, framework-agnostic across LangChain, CrewAI, LiteLLM, and OpenAI (Source: Microsoft Foundry blog).
  • Microsoft Scout and Project Solara are the first consumers of the stack, not the point of it.

What shipped at Build 2026: the trust stack in one view

The announcements look scattered until you stack them. Identity, isolation, control, and evaluation are the four problems every production agent deployment hits, and Microsoft shipped one answer for each (Source: Microsoft Foundry blog). The point is not four products. It is that they compose into a single chain of custody for agent work.

Read the stack bottom-up: an agent gets an identity, runs inside a sandbox, passes through control checkpoints on every action, and is scored against policy after the fact. Each layer ships as an open spec or open-source repo, which is the part that makes it credible beyond Microsoft's own tools.

This is the governance half of Microsoft's agent story. The build half - graph workflows and Model Context Protocol support - shipped earlier in the Microsoft Agent Framework 1.0 release, and the two halves are designed to meet.

Layer 1: Agent identity with Entra Agent ID

The foundational move is giving an agent its own identity. On Windows, each agent gets either a local ID or a cloud-provisioned identity backed by Entra, and all of its container activity is attributed to that specific identity (Source: Windows Developer blog). That single decision changes how every other layer works.

The contrast is with how teams run agents today. Most production agents authenticate as a shared service account, which means the audit log shows one actor doing the work of fifty. Why this matters: when every agent carries its own governed Entra identity rather than a shared, anonymous account, the work it does is attributable to a known actor your directory already understands (Source: Microsoft 365 blog).

Governance rides on top through Agent 365, which layers Defender, Entra, Intune, and Purview protections over the runtime; that protection set enters preview in July (Source: Windows Developer blog). Defender adds real-time protection against prompt-injection attacks, and Intune policies enforce the sandbox guardrails described in the next layer.

Operator note (first-hand): the first thing to audit before adopting any of this is service-account sprawl. Pull your agent inventory and count how many distinct agents share a single credential today. That number is your blast radius, and per-agent Entra identity is the only thing on this list that shrinks it directly. Map each shared account to a named owner before you provision a single agent identity.

Layer 2: Isolation with Microsoft Execution Containers (MXC)

Identity tells you who; isolation decides what they can touch. MXC, short for Microsoft Execution Containers, is a cross-platform, policy-driven execution layer for agents on Windows and WSL that lets developers declare what an agent can access - files, network - with containment boundaries enforced at runtime (Source: Windows platform security blog). The sandboxes are kernel-enforced, not advisory.

The useful idea is the composable sandbox spectrum: you pick the containment level that matches the risk of the workload. The options run from lightweight to hardware-backed:

  • Process isolation: restricts file and network access inside the user environment. GitHub Copilot CLI already uses it to constrain dynamically generated code (Source: Windows platform security blog).
  • Session isolation: separates agent execution from the user desktop, clipboard, and input devices to block UI spoofing and input injection.
  • Micro-VM: hardware-backed hypervisor isolation for high-risk workloads (roadmap).
  • Linux containers and Windows 365 for Agents: WSL-based containment and cloud-PC isolation with Intune policy (roadmap).

The cross-framework signal matters more than any single backend. MXC is in early preview with an SDK landing shortly after Build, and its repo is public at github.com/microsoft/mxc (Source: Windows platform security blog). The open-source OpenClaw runtime runs inside MXC, and NVIDIA's OpenShell runtime for Windows is built on it too (Source: Computerworld). If sandboxing is your entry point to this topic, our breakdown of native sandboxes in the OpenAI Agents SDK covers the same problem from the SDK side.

Layer 3: Control checkpoints and the Agent Control Specification

Sandboxing bounds the environment; the Agent Control Specification (ACS) bounds the behavior. It is an open industry specification for placing deterministic safety and security controls at checkpoints throughout agentic workflows (Source: Microsoft Foundry blog). Deterministic is the operative word: these are rule-based gates, not a model judging itself.

ACS defines five validation checkpoints across an agent's lifecycle: input, the large language model call, state, tool execution, and output (Source: Microsoft Foundry blog). The tool-execution checkpoint is the one to watch, because that is where agents reach into the real world. It is exactly the class of risk we covered in the CSA write-up on an MCP "by design" remote-code-execution issue - a checkpoint there is a real mitigation, not a checkbox.

The controls are expressed as standard policy YAML, which makes them portable, versionable, and auditable (Source: Microsoft Foundry blog). Decision rule: if a control cannot be diffed in a pull request, it is not governance, it is a vibe. Policy-as-YAML is what lets a security team review agent controls the same way they review infrastructure. Early customers include KPMG and Zscaler, and the repo lives at github.com/microsoft/agent-governance-toolkit (Source: Microsoft Foundry blog). For a parallel take on policy at the tool boundary, see how SnapLogic frames the governed tool layer.

Layer 4: Evaluation with ASSERT

The top layer answers the question the other three cannot: did the controls actually hold? ASSERT - Adaptive Spec-driven Scoring for Evaluation and Regression Testing - is an open-source, policy-driven evaluation framework built on Microsoft Research that converts your policies into concrete, measurable evaluations (Source: Microsoft Foundry blog).

The framing is requirements-in, tests-out. You give it organizational policy; it produces evaluations and regression tests you can run continuously, so a policy is no longer a document nobody checks. ASSERT is framework-agnostic, working across LangChain, CrewAI, LiteLLM, OpenAI, and more, with launch partners including Arize AI, LiteLLM, Pipecat, and Pydantic (Source: Microsoft Foundry blog). The repo is at github.com/responsibleai/ASSERT.

Why this matters: evaluation is where most agent governance programs quietly fail. Teams write a policy, ship the agent, and never close the loop. An eval-and-regression layer makes the policy executable, which is the difference between governance you can audit and governance you can only assert in a meeting.

Why "open" is the real story

Strip away the product names and the durable news is the openness. ASSERT, ACS, and MXC ship as open repos or open specs, the controls are framework-agnostic, and Microsoft is contributing policy conformance directly upstream to the OpenClaw runtime so any organization running it can get a verifiable, audit-ready answer about its configuration (Source: Microsoft 365 blog).

The point is not Windows lock-in. It is portable governance. An open spec for control checkpoints and a cross-platform sandbox layer mean a platform team can adopt the governance model without betting the company on one vendor's agent framework or one model provider. That is the bet worth tracking: trust as shared infrastructure rather than a proprietary moat. Whether the broad partner list - IBM, Monte Carlo, Obsidian, Aviatrix, and more on ACS - turns into real interop is the open question for the next six months (Inference: based on the announced partner roster, not yet shipped integrations).

Scout and Solara: the stack's first consumers

The two flashiest Build announcements are best read as proof that the stack works. Microsoft Scout is an always-on personal work agent in a new category Microsoft calls Autopilots, built on the open-source OpenClaw runtime with Work IQ as its context engine (Source: Microsoft 365 blog). Crucially, each Autopilot operates under its own governed Entra identity rather than a shared service account, and its skills run inside MXC sandboxes - the trust stack in production. Scout is an experimental release through Frontier, gated behind Frontier enrollment, Intune policy configuration, and an opt-in attestation (Source: Microsoft 365 blog).

Project Solara pushes the stack off the PC entirely. It is a chip-to-cloud platform for agent-first devices that run agents instead of apps, built on a lightweight edge OS called MDEP (Microsoft Device Ecosystem Platform) on the Android Open Source Project, paired with Azure-hosted agent services and persistent cloud state (Source: Tom's Hardware). Two concept devices, a wearable badge and a desk companion, are piloting with Best Buy, CVS Health, Levi's, and Target (Source: GeekWire). The governance story matters more than the hardware: identity and policy follow the agent across form factors. This is the same runtime-as-platform pattern we traced in Claude Managed Agents turning agent runtime into an API.

How to adopt: a decision rule for platform teams

Treat the stack as four independent adoption decisions, not one. The layers compose, but you do not have to take them all at once.

  • Identity (adopt first): if you already run Entra and Intune, per-agent identity is the lowest-risk, highest-leverage layer. Inventory shared service accounts and start migrating agents to governed identities now.
  • Control (pilot now): the Agent Control Specification is an open spec you can read and prototype against today. Start with the tool-execution checkpoint, where the real-world blast radius lives.
  • Isolation (pilot in non-prod): MXC is early preview. Test process isolation against your highest-risk agent in a non-production session before it reaches general availability.
  • Evaluation (wire in early): stand up ASSERT against one written policy now, so the eval loop exists before your agent fleet grows past the point where you can reason about it manually.

Decision rule: adopt identity because it shrinks blast radius immediately, prototype control and evaluation because they are open and cost only engineering time, and stage isolation behind general availability because it is still preview. The Agent 365 governance bundle (Defender, Entra, Intune, Purview) entering preview in July is the date to put on the calendar (Source: Windows Developer blog).

FAQ

What is the Microsoft agent trust stack?

It is the four-layer governance model Microsoft shipped at Build 2026 for running AI agents: Entra Agent ID for identity, MXC for sandboxed isolation, the Agent Control Specification for policy checkpoints, and ASSERT for evaluation (Source: Microsoft Foundry blog).

Are ASSERT, ACS, and MXC open source?

Yes. ASSERT is open source at github.com/responsibleai/ASSERT, the Agent Control Specification toolkit is at github.com/microsoft/agent-governance-toolkit, and MXC is at github.com/microsoft/mxc. ACS is published as an open industry specification (Source: Microsoft Foundry blog).

What is Entra Agent ID?

It is a governed identity assigned to each agent - either a local Windows ID or an Entra-backed cloud identity - so every action an agent takes is attributable to a known actor instead of a shared service account (Source: Windows Developer blog).

Is Microsoft Scout generally available?

No. Microsoft Scout is an experimental release through Frontier and requires Frontier enrollment, Intune policy configuration, and an opt-in attestation (Source: Microsoft 365 blog).

Does MXC only work on Windows?

No. MXC is a cross-platform execution layer for agents on Windows and WSL, and it already backs third-party runtimes including OpenClaw and NVIDIA's OpenShell (Source: Windows platform security blog).

What is Project Solara?

Project Solara is a chip-to-cloud platform for agent-first devices that run AI agents instead of apps, built on the MDEP edge OS and Azure-hosted agent services, with concept devices piloting at Best Buy, CVS Health, Levi's, and Target (Source: Tom's Hardware).

References