Microsoft shipped containment (MXC) and governance (Agent 365) for local AI agents. But containment answers "what could the agent access?" It does not answer "what did the agent actually do?" This guide maps the evidence gap and the procedures that close it.
Who this is for: Windows enterprise architects, CISOs deploying local AI agents, Intune and Entra administrators governing agent fleets, GitHub Copilot administrators evaluating hybrid local/cloud routing, developers building inside MXC containers, and assessors reviewing endpoint AI governance for EU AI Act or NIST AI RMF compliance.
CRITICAL ASSESSOR NOTICE: SWT3 witness anchors record that a governance event occurred and capture its computational factors. They do not replace assessor judgment. The assessor must independently verify that the substance of each control implementation meets the requirements of the applicable framework. Anchors provide the evidence trail; the assessor determines whether that evidence is sufficient.
On October 7, 2026, Microsoft announced a transformation of Windows into a platform for local AI agent execution. The announcements span hardware, models, containment, and governance:
| Component | What It Is | Status |
|---|---|---|
| MAI-Code-1.1 Flash | 137 billion total parameters, 6.8 billion active (sparse mixture-of-experts). 256K context window. Runs locally at 3-bit precision (~53 GB). 70.80% on SWE-Bench Verified on-device. | Rolling out via GitHub Copilot |
| MXC | Policy-driven execution containers for AI agents. Filesystem, network, and UI constraint layers. Cross-platform (Windows, Linux, macOS). | GA on Windows 11 |
| Agent 365 | Enterprise governance plane for agent fleets. Entra identity, Intune policy, Purview data governance, Defender threat detection. | GA (GCC October 1) |
| Surface Laptop Ultra | NVIDIA RTX Spark (Grace ARM + Blackwell GPU). Up to 128 GB unified memory. Up to 1 petaflop FP4. Runs 120B+ parameter models locally. | Shipping October 16 |
| GitHub Copilot Hybrid | HydraFusion routing between local (MAI-Code-1.1 Flash) and cloud models based on task complexity and hardware capability. | Limited preview end of October |
The strategic direction is clear: AI agent execution is moving from cloud servers to local endpoints. This eliminates per-token cloud costs, enables private inference over sensitive codebases, and allows operation in environments with limited connectivity. But it also moves the compliance surface from the cloud (where providers manage logging and governance) to the endpoint (where the enterprise must build its own evidence infrastructure).
Microsoft Execution Containers (MXC) provide policy-driven isolation for AI agents. The system uses declarative JSON policies to define three constraint layers:
MXC supports multiple isolation backends depending on the platform. On Windows, the default is ProcessContainer (AppContainer-based), with options for Windows Sandbox, WSL containers, MicroVM, and Hyperlight. On Linux, the default is Bubblewrap (namespace + seccomp isolation). On macOS, Seatbelt sandbox profiles are used.
The hypervisor-backed isolation option is notable: containers share no kernel objects with the host, providing VM-grade isolation at near-native startup speed (single-digit milliseconds). This is a meaningful security improvement over Docker, which shares the host kernel.
MXC is open source and already adopted by Codex (OpenAI), GitHub Copilot, Replit, LM Studio, NVIDIA OpenShell, and others.
What MXC does well: MXC answers the question "what could this agent access?" with policy enforcement at the OS level. If the filesystem policy says the agent can only read src/components/, the agent cannot read ~/.ssh/. This is a real security control that meaningfully constrains agent behavior.
Agent 365 is the enterprise control plane that makes Microsoft's existing management stack agent-aware:
Agent 365 also provides an Agent Registry that auto-discovers unmanaged agents on enterprise endpoints using Defender, Entra, and Intune working together. This addresses the "shadow AI" problem: agents installed by employees without IT approval.
Together, MXC and Agent 365 form a comprehensive containment and management layer. MXC isolates the agent's execution. Agent 365 governs the agent's identity, access, and data handling. This is a substantial enterprise security offering.
MXC and Agent 365 answer critical security questions. But they do not answer the compliance question that assessors, auditors, and Notified Bodies ask: "Can you prove what the agent did inside the container?"
| Question | MXC + Agent 365 | Witness Evidence |
|---|---|---|
| What could the agent access? | Yes. Filesystem, network, and UI policies define the boundary. | Not needed. MXC policy is the answer. |
| What did the agent actually do? | Partial. Telemetry logs capture commands, API calls, and resource usage, but logs are ephemeral and lack tamper-evident structure. | Yes. Structured attestation records with cryptographic fingerprints. |
| Did the agent stay within its declared scope? | No native mechanism to compare declared scope vs. actual behavior. | Yes. AI-ACC.1 captures declared vs. actual scope and records mismatches. |
| Can an independent party verify the evidence? | No. Telemetry flows through Microsoft's infrastructure. The assessor must trust the deployer's logs. | Yes. Witness anchors are independently verifiable against the ledger. |
| Is there a continuous evidence chain between assessments? | No. MXC does not produce structured evidence on a defined cadence. | Yes. Attestation cadence is configurable and gaps are detectable. |
| Can the evidence reconstruct a multi-agent decision chain? | No. MXC provides per-container isolation but no cross-agent lineage. | Yes. Lifecycle chains link related attestations across agents. |
This is not a criticism of MXC. MXC is designed to be a sandbox, not a witness system. It excels at containment. The gap is that containment alone does not satisfy regulatory frameworks that require evidence of what happened, not just evidence of what was permitted.
The MCP audit logging gap: MCP servers running inside MXC containers have no standard for what gets captured, how long it persists, or who can access the logs. Logs are ephemeral, inconsistent across servers, and lost on process restart. For compliance frameworks that require durable, verifiable audit trails, this is a structural limitation of the current MCP + MXC combination.
The following procedures produce evidence that complements MXC containment and Agent 365 governance. They operate inside the MXC container, alongside the agent, producing structured attestation records that the agent itself cannot modify or delete.
Records that an AI agent was operating within its declared containment boundary. For MXC deployments, this witnesses the MXC policy state at the time of agent execution: what filesystem paths were permitted, what network access was allowed, and what UI capabilities were available. This transforms MXC's runtime policy enforcement into a durable evidence record.
Verify that containment attestations capture both the MXC policy definition and the observed agent behavior. A policy that permits access to a directory is not the same as evidence that the agent accessed only that directory. The attestation should record both the boundary and the activity within it.
Records every tool call an agent executes inside the MXC container: terminal commands, file operations, API calls, and MCP tool invocations. For GitHub Copilot hybrid routing, this captures both local (MAI-Code-1.1 Flash) and cloud-routed tool calls, creating a unified evidence trail regardless of where the inference ran.
For hybrid routing (HydraFusion), verify that tool execution attestations distinguish between locally-executed and cloud-routed operations. An assessor reviewing a hybrid deployment needs to know which decisions were made by the local model (with its on-device privacy guarantees) and which were routed to the cloud (with its different data handling implications).
Records that access controls were enforced at the time of agent operation. For MXC deployments, this is the bridge between the policy (what was configured) and the reality (what was accessed). The attestation captures the declared scope (the MXC policy's filesystem, network, and UI permissions) alongside the actual resources the agent touched.
The most valuable signal in an access control attestation is a mismatch between declared and actual scope. If the declared scope permits access to project files but the attestation records access to system configuration, that mismatch is a control failure. Even if MXC blocked the access at the OS level, the attempt should be witnessed.
Records identity verification for the agent. Agent 365 provides Entra-managed identities for agents. AI-ID.1 witnesses that the identity was verified at the time of operation, creating a durable record that links a specific agent identity to a specific set of actions inside a specific MXC container session.
In enterprise deployments with multiple agents, verify that each agent has a distinct identity and that attestations are per-agent, not per-device. A single laptop may run multiple agents in separate MXC containers. Each agent's evidence chain should be independently traceable through its identity attestation.
Records cryptographic verification of model weight files at deployment and during operation. For local models like MAI-Code-1.1 Flash running at 3-bit quantization (~53 GB on disk), weight integrity attestation proves the model on the endpoint matches the authorized version. This is important for enterprise deployments where models are distributed to thousands of endpoints.
Local model deployments face a unique integrity risk: the weights live on user-accessible storage. Unlike cloud-hosted models where the provider controls the artifact, local weights can potentially be modified by the device user or by other software. Weight integrity attestation on a regular cadence detects unauthorized modifications.
Records that audit logging infrastructure was operating inside the MXC container. This addresses the MCP audit logging gap directly: even though MCP servers inside MXC do not have a native standard for durable logging, the audit trail attestation provides a structured evidence layer that confirms logging was active during the period under review.
MXC container sessions can be ephemeral. Verify that audit trail attestations persist beyond the container lifecycle. Evidence that disappears when the container is deprovisioned provides no value to an assessor reviewing the organization's compliance posture after the fact.
MXC is cross-platform (Windows, Linux, macOS), and enterprise fleets are heterogeneous. The evidence layer must work everywhere the agents run.
| Platform | MXC Backend | SWT3 SDK |
|---|---|---|
| Windows (.NET) | ProcessContainer (AppContainer), Windows Sandbox, Hyperlight | C# / .NET SDK (NuGet) |
| Linux (Python/Node) | Bubblewrap (namespaces + seccomp), LXC, MicroVM | Python SDK (PyPI), TypeScript SDK (npm) |
| macOS (Swift) | Seatbelt (sandbox-exec profiles) | Swift SDK (Swift Package Index) |
| Kubernetes | Not applicable (K8s has its own isolation) | swt3-witness DaemonSet (GHCR Helm chart) |
The witness protocol produces identical attestation records regardless of platform. An assessor reviewing evidence from a mixed Windows/macOS/Linux fleet sees the same attestation format, the same fingerprint formula, and the same verification process. The SDK handles platform differences; the evidence is uniform.
The complementary relationship: MXC and SWT3 are not competing systems. MXC provides the containment envelope. SWT3 provides the evidence trail inside that envelope. MXC stops the agent from doing things it should not. SWT3 proves what the agent actually did. Enterprise deployments need both: security teams use MXC for prevention, and compliance teams use witness evidence for accountability.