Microsoft just sandboxed your AI agent (MXC explained + real demo)
Read the Portuguese translation →
Author: Prompt Engineer 48 · Watch on YouTube
Video authored by the channel shown, not by IANIA; all rights belong to the creator. Transcript and summary generated automatically; the original-language content is preserved.
Original language: English
Original video: Microsoft just sandboxed your AI agent (MXC explained + real demo) · Channel: Prompt Engineer 48 · 04:40 · Watch on YouTube
Topics: AI agents, Cybersecurity and software security, AI developer tools, Markets and economy, AI safety
Summary
Section titled “Summary”The video explains Microsoft Execution Containers (MXC), a policy-driven execution layer that restricts what an AI agent can access and do. It describes MXC’s policy areas, four container backends, and enforcement, learning, and permissive modes. A Windows demo shows policies blocking access to an unapproved file, preventing writes to a read-only folder, and controlling network access. The video also notes current limitations, including the public-preview SDK and experimental stronger backends, and recommends starting with a process container and a deny-by-default policy.
Key points
Section titled “Key points”- MXC is designed to sandbox untrusted or dynamically generated code, including model output, plugins, tools, or an entire agent.
- Policies define containment, process settings, file-system access, network access, and desktop or clipboard permissions.
- The policy cannot be changed by the agent, and a shared schema and SDK are available for Rust, .NET, and Node.
- The four backends are process containers, session containers, WSL containers, and an experimental micro VM.
- Enforcement applies the policy; learning blocks ungranted actions and records them; permissive allows actions while logging what would have been denied.
- In the demo, the sandbox can read an authorized folder but cannot read a neighboring secret.env file or write to the read-only folder.
- Network egress denial blocks a curl request, while allowing it lets the request return HTTP 200.
- The SDK is in public preview, the activity report works only on Windows process containers, and some host allow/block lists are not yet enforced on Windows.
- The video recommends starting with a process container and a deny-by-default policy when agents access real files or credentials.
Chapters
Section titled “Chapters”| Start | Chapter | Summary |
|---|---|---|
| 00:00 | The agent access problem and MXC | The video introduces the risks of giving an AI agent broad access and presents MXC as a policy-based alternative. |
| 01:00 | Policies, backends, and modes | It outlines the areas controlled by an MXC policy, its four backends, and its enforcement, learning, and permissive modes. |
| 02:03 | Live sandbox demonstrations | A Windows demo shows MXC controlling file reads, writes, and network access according to the policy. |
| 03:37 | Adoption, benefits, and limitations | The video names reported users and integrations, highlights MXC’s benefits, and describes preview-stage caveats. |
| 04:09 | Recommendation | The video recommends MXC for agents handling real files or credentials, starting with a process container and deny-by-default policy. |
Quotes
Section titled “Quotes”Prompts that say, “Please do not touch this folder.” are not a security boundary. — 00:30
The agent cannot change its own policy. — 01:00
Read-only means read-only. — 02:35
Containment is not about distrusting the model. It is about making the blast radius a number you chose. — 03:06
Start with a process container and a deny by default policy. — 04:40
Concepts and entities
Section titled “Concepts and entities”Microsoft Execution Containers (MXC), Microsoft, agent harness, Windows 11, WSL, GitHub Copilot, OpenClaw, OpenAI Codex, Replit, LM Studio, Unsloth, Perplexity, NVIDIA, OpenShell
Full transcript (original language)
Section titled “Full transcript (original language)”00:00 Your AI coding agent has the same access you do, your files, your network, your production config, and it decides what to do with all of it on its own. Microsoft just shipped a fix, and it is called MXC. Here is the problem. Say you ask an agent to update your website. To do that, it needs the repo and the build tools, but it can also read your production server configuration, and one day it decides to change it. The choice looked reasonable to the agent. It was never what you meant to allow.
00:30 So, today you have two bad options. Give the agent unrestricted access and hope nothing goes wrong, or block it and lose the productivity that made agents worth using in the first place. Prompts that say, “Please do not touch this folder.” are not a security boundary. MXC stands for Microsoft Execution Containers. It is a policy-driven execution layer for untrusted or dynamically generated code. Model output, plugins, tools, the agent harness, or the whole agent, you declare
01:00 what the workload needs, files and network destinations, and MXC enforces that boundary. The agent cannot change its own policy. The policy covers five areas: containment, which isolation environment to use, process, the command and its environment, file system, what is writable, read-only, or inaccessible, network, inbound and outbound, including loopback and user interface, the desktop and the clipboard, one JSON schema, and one SDK in Rust, .NET, and Node. Under that, there are four backends. A
01:31 process container, which uses app container on Windows, seatbelt on macOS, and bubble wrap on Linux. A session container with its own identity and desktop. A WSL container for Linux toolchains. And a micro VM experimental for the riskiest workloads. You pick the strength, the policy stays the same. There are also three modes. Enforcement applies the policy. Learning blocks what is not granted and records it in a JSON activity report, so you can see why something failed. And permissive lets everything through, but records what the
02:03 policy would have denied. That is how you author a policy without guessing. Enough slides, let us run it. This is my own Windows 11 laptop build 26,300. I installed the real node SDK from NPM version 0.8. First, the platform check supported back-end process container, the UI restrictions, clipboard, input injection, desktop switching, all blockable. Demo one, the file system. I gave this sandbox read-only access to one folder. Reading the file inside it works. Now I
02:35 ask it to read secret.env, which sits next to that folder, not inside it. Access is denied. Same command, same machine, no fancy tricks. The policy decided. Demo two, same read-only folder, but now the agent tries to write a file there. Echo pound into evil.text, access is denied again. Read-only means read-only. The agent can look, it cannot touch. Demo three, the network. Same curl command hitting example.com. With egress
03:06 set to deny, it fails. Exit code six, could not resolve host. I flip one line in the policy to allow, same command, and it returns HTTP 200. That one line is the whole difference between an agent that can exfiltrate data and one that cannot. Here is that idea as a picture. The agent tries to read your SSH keys, blocked. It tries to post to an unknown server, blocked. It writes to the repo it was given, allowed. Containment is not about distrusting the model. It is about making the blast radius a number
03:37 you chose. And this is not a lab toy. Microsoft says GitHub Copilot, OpenClaw, OpenAI Codex, Replit LM Studio, and Unsloth already use it. Cloud Code Box, Perplexity, and others are announced. Nvidia integrated Open Shell on top, adding credential management and audit logging. What I like. One policy across Windows, macOS, and Linux. Real OS level enforcement, not a prompt. The agent cannot edit its own policy. Learning and permissive modes make writing policy
04:09 practical, open source under MIT, and it scales from a process all the way up to a VM. What to watch. The SDK is public preview and schemas can still change before 1.0. The activity report only works on Windows process containers. Host allow and block lists are not enforced on Windows yet. Only default allow or block. The strongest backends are experimental and the published NPM package did not match the samples in the repo. So, expect some friction. So, should you use it? If your agent
04:40 touches real files or real credentials, yes. Start with a process container and a deny by default policy. Links to the blog and the repo are in the description. If this was useful, like, subscribe, and I will see you in the next one.