AI Agent Containment: A Business Checklist for MXC

Start with the boundary, not the agent's promise

Before approving an AI agent pilot, ask your implementation partner to demonstrate what the agent cannot access. A successful task is only one acceptance condition; the proposed permissions should also match the work you authorized.

Microsoft describes Microsoft Execution Containers (MXC) as a policy-driven execution layer for untrusted code and dynamically generated workloads. Developers can contain generated output, plugins, tools, an agent harness or the entire agent. The resource policy sits outside the workload's control, so the agent cannot grant itself additional access.

Use the checklist below to turn that design into procurement questions and pilot evidence. These are recommended evaluation steps, not a claim that a particular deployment has passed security testing.

Separate available controls from planned features

Microsoft's announcement describes MXC as generally available. It separately labels Intune policies for managing Windows 11 MXC process containers, and Entra-based agent attribution in Agent 365, as coming soon. Keep those distinctions in your requirements: the announcement does not establish that the planned management and attribution features are already available. Source: Microsoft announcement.

Ask your supplier to identify the application integration, SDK version, host operating system and selected backend before discussing coverage. The official repository describes MXC as an SDK dependency built into an application, with Rust, .NET and Node SDKs. The application specifies the container type, rules and workload command; MXC validates the request and launches the workload through a backend.

Request evidence for the integration you will actually deploy. Do not accept a general product announcement as the acceptance record for your own application.

Write a resource inventory before granting access

Microsoft's documented example is a coding agent updating a website. It needs read/write access to the repository and development tools, but may need only read access to production server configuration. Containment is intended to prevent a configuration change even if the agent decides that changing it would help complete the task. Source: Microsoft's website example.

Use that example as a requirements worksheet, not as permission to expose your production environment. Ask the technical team to document:

• Writable locations: which repository and output paths are required?
• Read-only locations: what must be inspected without modification?
• Denied locations: which unrelated files must remain inaccessible?
• Execution settings: which commands, arguments, working directory and environment are needed?
• Network access: which inbound, outbound and host-loopback connections are necessary?
• Desktop access: does the workload need UI interaction at all?

These questions correspond to Microsoft's documented process, filesystem, network and UI policy areas. The repository also specifies read-only, read-write and denied path lists, plus clipboard, display and GUI controls.

For an AI development project, make this inventory a reviewable deliverable. Require a business reason for each requested permission and an identified reviewer for later changes.

Choose a backend against the actual workload

Do not treat “runs in MXC” as a complete technical specification. Microsoft explicitly says that the backends have different security properties. Its containment overview describes these choices:

• Process containment: available on Windows 11, macOS and Linux, using AppContainer, Seatbelt and Bubblewrap respectively; positioned for responsive workloads and tool execution.
• Session containment: Windows 11 only, with a distinct account and session separating the agent's desktop, clipboard, UI and input from the user.
• WSL containment: Windows 11 only, providing a Linux environment for Linux-first toolchains.
• MicroVM: described in the announcement as experimental on Windows 11 and Linux, with hardware-enforced isolation.

Ask the supplier why its selected backend fits the workload and which requested controls it cannot provide. The repository describes host filtering as backend-dependent, so do not assume identical network-destination controls across platforms.

Record the backend and host used for acceptance testing. If either changes, require a review of the affected controls rather than relying on the earlier demonstration.

Distinguish enforcement from observation

The announcement's operating-mode table makes an important distinction:

Mode	Ungranted access	Activity report
Enforcement	Blocked	No
Learning	Blocked and recorded	Yes
Permissive	Allowed and recorded	Yes

Microsoft limits this activity-report capability to Windows MXC process containers. Its denied-access documentation likewise limits learning-mode capabilities to Windows AppContainer-based backends.

For a boundary test, request blocked-and-recorded Learning mode where supported. A permissive observation run is not evidence that unauthorized operations were prevented. Microsoft says Permissive mode allows access that the container policy would otherwise deny, while other applicable operating-system and organizational restrictions still apply.

Be particularly careful with diagnostic terminology. The repository explicitly warns that --audit turns off sandbox security for the analyzed workload and must never be used to run untrusted code. Do not let an “audit” label substitute for an explanation of what remains enforced.

Define denied-access tests before the pilot

Translate the approved resource inventory into pass/fail checks. The following proposed tests derive from Microsoft's website example and documented policy areas; they are not reported MXC test results. Use a controlled test environment and non-sensitive test resources.

1. Complete the permitted task. Demonstrate the website change within the approved repository and tool access. Keep the resulting output for review.
2. Attempt a prohibited write. Test modification of the configuration resource designated read-only. Require evidence that the write was denied and the resource remained unchanged.
3. Attempt unrelated file access. Test a location deliberately excluded from the workload's permissions. Require denial rather than an agent message promising not to read it.
4. Exercise network restrictions. Test the disallowed connectivity relevant to the selected backend, including host loopback if it is part of your requirements.
5. Check permission-failure handling. Require a clear explanation when the permitted task cannot finish, rather than silent failure or an unapproved expansion of access.

The last condition follows Microsoft's guidance: an agent blocked by organizational policy should explain the limitation, request appropriate action where supported, or choose a safe alternative.

Where denial capture is supported, inspect the report as well as the user-facing result. The official report example includes resource identifiers, access types and a summary with a truncation indicator. Check that indicator before treating the captured denials as complete evidence.

Require a reviewable handover

Before expanding the pilot, request a compact evidence package: the resource inventory, approved policy, selected backend and host, operating mode, permitted-task result, denied-access results and unresolved limitations. Ask who approves policy changes and how the team will demonstrate that the approved restrictions remain in place.

For a business automation engagement, include those items in the delivery criteria rather than evaluating only whether the workflow finishes.

Approve the pilot against demonstrated boundaries, not planned features or broad security assurances. If a required restriction or reporting capability has not been demonstrated on the chosen configuration, mark it as unverified and resolve it before expanding access.