今年のBuildで、マルチプラットフォームでポリシー駆動のサンドボックス型コード実行システムであるMicrosoft Execution Container(MXC)が発表されました。
- microsoft/mxc: Policy-driven, layered isolation and containment
- Windows platform security for AI agents – Windows Developer Blog
- Build 2026: 信頼できる開発プラットフォームとして、進化する Windows – Source Asia
- [速報]Windows上でLinuxコンテナの作成や実行ができる「WSL containers」発表 - Publickey
- 「Microsoft Execution Containers」(MXC)が発表 ~「OpenClaw」などを安全に隔離する基盤 – 窓の杜
簡単にいうとプロセス単位でサンドボックス内で実行するためのランナーなのですが、必要に応じてアクセスできるフォルダーやアクセス権、ネットワーク制限などをきめ細かく設定できるランナーです。
背景的にはコーディングアシスタントでガシガシ自分のPC上で動かすケースが増えたけど事故の発生やセキュリティリスクの増大などが問題になってますよね。そうなってくると安全に実行できるように分離したいわけですが、大体のサンドボックス環境はOSレベルから別物で、単純な処理の実行だけならともかく昨今のAutopilot的な処理やコーディングアシスタントのように多数のファイルや開発環境(ユーザーの環境)を使いながら分離するには結構大変な状況でした。(都度セットアップしたりファイルのコピーが必要だったり、、)とてもじゃないですがお手軽ではないです。そうのもあって、利便性が高くて安全なサンドボックス環境が求められるという感じです。
そんなわけで今回発表されたMicrosoft Execution Containerは現在の要望を満たせるよう、サンドボックスによる分離と、分離した環境でのプロセスの実行や制御が簡単にできる機能を提供してくれる感じです。※ OpenClaw for WindowsとかNVIDIA OpenShellとかMicrosoft Scoutも裏はこれ使ってるって話でしたっけ? Agent 365との統合も今後あるとかなんとか。
注意:そもそも現状は初期プレビューでもろもろ開発中という状態です。フィードバックはGitHubリポジトリへどうぞ。
特徴
- クロスプラットフォーム … Windows、Linux、macOSそれぞれで適したContainment(封じ込め)バックエンドをサポート。
- 複数のContainmentサポート … ProcessContainer, Windows Sandbox, LXC, Bubblewrap, Seabelt, MicroVM(NanVix), IsolationSession, WSLC (WSL Container)
- ポリシー主導 … ファイルシステムポリシー(Read only / Read Write パスリスト)、ネットワークポリシー(Proxyサポート、Outbound/ホストフィルタ、UIポリシー(クリップボードやディスプレイ、GUIアクセス制御)など。※ OSによってまだ未対応だったりがあります
- State-aware Lifecycle … セッションサンドボックスのライフサイクル(デプロイ、開始、停止、デプロイ削除)
- TypeScript SDK … NPMパッケージ @microsoft/mxc-sdk – npm でコードからMXCを制御
- 診断 … WindowsのデバッグログとETWでトラブルシューティング
セットアップ
最新を追いかけたい場合はGitHubからソースを落としてきてビルドする必要がありますが、初期リリース版として v0.6.1 がリリースされてるのでそちらを使うと楽です。ただこちらは現状Windows向けのバイナリしかなさそうなのでLinux/macOSで試したい方はビルドが必要かな?
ちなみにWindowsの前提条件は以下のように書いてますが、実際には 25H2でもうまく動きませんでした。(26300台のInsider Previewだったら問題なかった)(Issueになってる)
processcontainer: 26100 (24H2)isolation_session: 26300.8553 (Insider Preview)
バイナリを入手したらメインの wxc-exec.exe を使う前にホストを準備します。(Windowsの場合)
同根されてる wxc-host-prep.exe を実行することでAppContainer他サンドボックス権限などなど必要な準備をしてくれるようです(要UAC昇格)。※ このあたりは正式版には改善してそうですね。
管理者権限のコンソールで prepare-system-drive、 prepare-null-device、verify-null-deviceの3つのサブコマンドを実行すればよさそうです。
❯ .\wxc-host-prep.exe prepare-system-drive
Adding metadata-read ACEs on C:\
mask : 0x00120088 (FILE_READ_ATTRIBUTES | FILE_READ_EA | READ_CONTROL | SYNCHRONIZE)
+ ALL APPLICATION PACKAGES (S-1-15-2-1)
+ ALL RESTRICTED APPLICATION PACKAGES (S-1-15-2-2)
Done.
❯ .\wxc-host-prep.exe prepare-null-device
prepare-null-device: no-change
❯ .\wxc-host-prep.exe verify-null-device
verify-null-device: match
❯ .\wxc-host-prep.exe dump-null-device
O:BAG:SYD:(A;;0x1201bf;;;WD)(A;;FA;;;SY)(A;;FA;;;BA)(A;;0x1200a9;;;RC)(A;;0x1201bf;;;AC)(A;;0x1201bf;;;S-1-15-2-2)S:(ML;;NW;;;LW)
使ってみる
まず実行対象にあわせたポリシーとなるJSONファイルを準備します。
- Configuration Schema
- mxc/schemas/stable/mxc-config.schema.0.6.0-alpha.json at main · microsoft/mxc
- ※ スキーマバージョンで多少変わりますがStable扱いの0.6.0-alpha使えばいいかなと思います。
とりあえず最低限Containmentをprocesscontainerにして実行するプロセスとか許可するファイルパスなどを指定してみましょう。
{
"version": "0.6.0-alpha",
"containerId": "my-container",
"containment": "processcontainer",
"process": {
"commandLine": "cmd",
"cwd": "c:\\temp\\mxctest"
},
"filesystem": {
"readwritePaths": ["c:\\temp\\readwrite"],
"readonlyPaths": ["c:\\temp\\mxctest", "c:\\temp\\readonly"]
}
}
JSONファイルができたら wxc-exec.exe に渡せばOKです。
.\wxc-exec.exe test.json
実行すると process で指定したプロセスが起動します。今回は cmd なのでコマンドラインが起動すると思います。
とりあえずfilesystem で指定したフォルダーをのぞいてみます。
c:\temp\mxctest>dir c:\temp\readonly
Volume in drive C has no label.
Volume Serial Number is 9E89-41E6
Directory of c:\temp\readonly
2026/06/06 03:27 <DIR> .
2026/06/06 03:08 <DIR> ..
2026/06/06 03:27 4 readonly_1.txt
2026/06/06 03:27 5 readonly_2.txt
2 File(s) 9 bytes
2 Dir(s) 152,803,893,248 bytes free
普通に見れますね。では何も明示的に許可してないパスを見てみます。
c:\temp\mxctest>dir c:\temp
Volume in drive C has no label.
Volume Serial Number is 9E89-41E6
Directory of c:\
File Not Found
実行フォルダーの親フォルダーなのも関わらず見れませんでした。
次は読み取り専用扱いのフォルダーにファイルを作ってみます。
c:\temp\mxctest>echo test > c:\temp\readonly\test.txt
Access is denied.
拒否されました。同じように読み書きできるパスを指定してみるとちゃんと書き込めるのがわかります。
c:\temp\mxctest>echo test > c:\temp\readwrite\test.txt
c:\temp\mxctest>dir c:\temp\readwrite
Volume in drive C has no label.
Volume Serial Number is 9E89-41E6
Directory of c:\temp\readwrite
2026/06/06 03:36 <DIR> .
2026/06/06 03:08 <DIR> ..
2026/06/06 03:36 7 test.txt
1 File(s) 7 bytes
2 Dir(s) 151,321,772,032 bytes free
※ 使うコマンドもWindowsフォルダーにないものを指定するとアクセス許可しない限り使えないのでエラーになったりします。
次はネットワーク周りです。明示的に許可しないと既定値はBlockです。Curlで試してみます。
c:\temp\mxctest>curl https://www.azure.moe
curl: (6) Could not resolve host: www.azure.moe
名前解決させない感じなんですね。ネットワークインターフェースとかはちゃんと見えてるので。なるほど?
フォルダーのACLとかは特に変わってませんが、実行プロセスのセキュリティみると特殊なSIDが居たりするので、このあたりであれこれしてるんでしょうかね。

起動時に –debug を付ければ何してるかいろいろ見れてデバッグに役立ちます。
❯ .\wxc-exec.exe .\schemas\test.json --debug
SECTION: Request simplified
Container ID: my-container
Platform: windows
Script code length: 3
Working directory: c:\temp\mxctest
Script timeout: 0
Container name: my-container
SECTION: Full `ExecutionRequest` configuration (redacted)
{
"schema_version": "0.6.0-alpha",
"container_id": "my-container",
"platform": "windows",
"env": [],
"script_code": "cmd",
"working_directory": "c:\\temp\\mxctest",
"script_timeout": 0,
"containment": "processcontainer",
"lifecycle": {
"destroy_on_exit": true,
"preserve_policy": false
},
"policy": {
"least_privilege_mode": false,
"capabilities": [],
"readwrite_paths": [
"c:\\temp\\readwrite"
],
"readonly_paths": [
"c:\\temp\\mxctest",
"c:\\temp\\readonly"
],
"denied_paths": [],
"fallback": {
"allow_dacl_mutation": true
},
"default_network_policy": "block",
"network_enforcement_mode": "capabilities",
"allow_local_network": false,
"allowed_hosts": [],
"blocked_hosts": [],
"ui": {
"disable": true,
"clipboard": "none",
"injection": false
},
"base_process_ui": {
"isolation": "container",
"desktopSystemControl": false,
"systemSettings": "none",
"ime": false
}
},
"lxc_config": {
"distribution": "",
"release": ""
},
"experimental_enabled": false,
"experimental": {
"test": null,
"windows_sandbox": null,
"wslc": null,
"isolation_session": null,
"seatbelt": null
},
"dry_run": false
}
[network_proxy: disabled]
Using BaseContainer-fallback dispatcher (schema version 0.6.0-alpha)
selected isolation tier: base-container
▶ SECTION: Backend runner 'BaseContainer'
▶ SECTION: Build sandbox spec
sandbox spec built (version=0.1.0, 168 bytes)
[token]
integrity: ⚪ system_default
app_container: ⚪ on (least_privilege: off)
[network]
<unspecified>
[ui subsystem]
win32k_system_calls: ❌ blocked
uilimits allowed ✅: <none>
uilimits blocked ❌: handles, read_clip, write_clip, sys_params, display, atoms, desktop, exit_windows, ime, injection (0x03FF)
▶ SECTION: Load API
loaded Experimental_CreateProcessInSandbox from processmodel.dll
▶ SECTION: Launch process
⚠ destroy_on_exit=true: overriding caller identity 'my-container' -> 'sandbox-73be8c821cbc52cf' for ephemeral cleanup
derived SID: S-1-15-2-2512708608-286552967-3722442598-617601797-3273276414-2879348764-192830413
tracking entry written: Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\ProcessSandboxes\Mappings\S-1-15-2-2512708608-286552967-3722442598-617601797-3273276414-2879348764-192830413
launching: cmd
identity: sandbox-73be8c821cbc52cf
AppContainerSID: S-1-15-2-2512708608-286552967-3722442598-617601797-3273276414-2879348764-192830413
process created (PID: 13688)
▶ SECTION: Wait for exit
Microsoft Windows [Version 10.0.26300.8497]
(c) Microsoft Corporation. All rights reserved.
Active code page: 65001
c:\temp\mxctest>
ProcessContainer以外にもWindows Sandboxとかサポートするぽいのですが、スキーマバージョンを0.7.0-devにして指定してみてもエラーになって動きませんでした。(メッセージ内のコマンドうって再起動してもダメだった)
Error: Windows Sandbox is not enabled. Run 'dism /online /enable-feature /featurename:Containers-DisposableClientVM /all' and reboot.
26300.8553のInsider Previewに上げたらWindows Sandboxは同じエラーですが、isolation_sessionのほうは動きました。Isolation Sessionは完全に別ユーザー/別ログインセッションで動作してますね。(IsolationProxy経由で動作してそう)

わかりにくいですが、サービス(分離環境ブローカー)配下で指定プロセスのCmdが動作してます。


Isolation Sessionにすると名前の通りログインセッションが別物になるようで、ユーザープロファイル(元ユーザー)が丸ごと別のものになるという感じですかね。以下のようなランダム?なプロファイルができてそれで起動していました。
USERNAME=F5-K5
USERPROFILE=C:\Users\F5-K5
まとめ
さすがに初期プレビューなのでかなり粗削りですが、ちゃんと使えれば便利に分離して作業ができそうです。楽しみですね。