🛡️ 技術調査 - Microsoft MXC：Windowsをエージェント実行基盤にする実行境界モデル

調査日: 2026-06-03 / 対象: MXC を中核に Agent 365 / Foundry hosted agents を含む「Windows をエージェント実行基盤にする」実行境界モデル
一次ソース: Windows Developer Blog（2026-06-02）、microsoft/mxc GitHub、Microsoft Build 2026 メインブログ、Microsoft Learn

概要

Microsoft は Build 2026（2026-06-02）で、AI エージェントを Windows / WSL 上で安全に動かす実行レイヤー MXC（Microsoft Execution Containers） をプレビュー公開しました。公式の定義は "a cross-platform, policy-driven execution layer for agents on Windows and WSL" です。開発者はエージェントに許すアクセス（ファイル・ネットワークなど）をポリシーとして宣言し、Windows が実行時にその境界を強制します。プラットフォーム全体の設計思想は "start secure and stay secure" と表現されています。

この発表は、AI エージェント導入の設計論点が「モデルが危険な指示を拒否するか（プロンプト）」から「どの権限で、どの環境に閉じ込め、何を監査するか（実行環境）」へ移ったことを示します。Microsoft はこれを 3 層で実装します。

• MXC … ローカル端末（Windows / WSL）でのエージェント隔離実行層
• Agent 365 … ホスト先・フレームワークに依存しない横断統制プレーン（Entra / Defender / Intune / Purview を束ねる単一コントロールプレーン）
• Foundry hosted agents（Azure AI Foundry）… クラウドホスト型エージェントの per-session VM 隔離サンドボックス

ここで重要な留保があります。公式リポジトリ microsoft/mxc は "no MXC profiles should be treated as security boundaries currently"（現時点でどの MXC プロファイルもセキュリティ境界として扱うべきではない）と明示します。現状は early preview の実装途上です。network の host filtering / outbound allow-block は Windows 未対応であるなど、機能はプラットフォームごとに途上にあります。本記事は「方向性（OS レベルで実行境界を扱う）は妥当だが、隔離だけでは不十分」という多層防御の前提で整理します。

特徴

• process isolation と session isolation の 2 段階隔離。process isolation はユーザー環境内の軽量 containment でファイル・ネットワークアクセスを制限します（coding agent など responsive な用途向け）。session isolation は interactive desktop / clipboard / UI / input devices / active sessions をユーザー環境から分離し、UI spoofing / input injection / cross-session data leakage を緩和します（long-running ワークフロー向け）。一次ソースの語は一貫して "mitigates" / "helps reduce"（緩和）で、完全防御を主張しません。
• JSON policy による宣言的制約。ポリシーは JSON schema で宣言し、現行スキーマは 0.6.0-alpha。Filesystem（read-only / read-write パスリスト）、Network（allow / block / host filtering）、UI（clipboard / display / GUI アクセス）の各制約を記述。
• TypeScript SDK（@microsoft/mxc-sdk）。低レベルの隔離詳細を直接扱わずにポリシーを定義できる抽象 SDK。one-shot 実行と状態管理ライフサイクルの両 API を備える。
• クロスプラットフォーム実装。ブログの打ち出しは Windows + WSL ながら、実装リポジトリは Windows / Linux / macOS の native wrapper をサポートし、複数の containment backend を 1 つの JSON schema と SDK の背後に統一。
• Intune ネイティブ統合。IT チームが Intune でポリシーを設定し、MXC が実行時に境界を強制。コンテナ内の全アクティビティはエージェントの local ID または Entra-backed identity に紐付き、full lifecycle governance を実現。
• Entra identity によるエージェント/人間の識別。session isolation はエージェントを distinct user account にバインドし、local ID または cloud-provisioned Entra identity を割り当て。人間とエージェントを明確に区別し、least-privilege access と auditability を担保。
• Agent 365 との統合ロードマップ。MXC 単体（SDK / process・session isolation）は Build 直後に Windows Insiders へ提供。Entra / Defender / Intune / Purview の 4 保護を組み合わせる Agent 365 native integration は July preview（2026 年 7 月）予定。
• 将来ロードマップ（未出荷）。Micro-VM、Linux containers、Windows 365 for Agents との MXC 統合が公式ロードマップに記載（一次: "currently on our roadmap"）。

構造

システムコンテキスト図

コンテナ図

コンポーネント図

データ

概念モデル

情報モデル

次の classDiagram は登場概念を正規化したモデルです。実際の SandboxPolicy JSON は filesystem.readwritePaths / readonlyPaths、network.allowOutbound / allowedHosts のようなオブジェクト構造で、図中の path / mode / host / action は概念表現です。実キーは「構築方法」の型定義を参照してください。

UIRule の display / gui の具体値域、Entra identity の objectId / upn / instanceId、ローカル MXC 単体の監査ログ API は一次本文で未確認です。Windows 未対応の network host filtering / denied paths は README に明記があります。

構築方法

前提（動作環境）

• Process / Session isolation は Build 2026 直後に Windows Insiders へ提供開始。
• isolation_session backend は Windows Insider Preview build 26300.8553 以降が必要。
• Experimental backend は { experimental: true } または CLI フラグ --experimental が必要。
• Agent 365 × MXC の native integration（Intune/Defender/Entra/Purview 連携）は 2026 年 7 月 preview 予定とされます（提供時期は一次情報の表現に揺れがあり、Build 直後〜数か月内の範囲で要確認）。MXC SDK 本体とは別タイムラインで進みます。

SDK インストール

@microsoft/mxc-sdk を利用します（Node.js 18 以上）。

npm install @microsoft/mxc-sdk

Windows ホスト準備（wxc-host-prep.exe）

Windows で AppContainer ベースの process isolation を使う場合、一度だけ管理者権限で wxc-host-prep.exe を実行します。

# AppContainer SID に C:\ ルートの最小権限 ACE を付与（一回限り、冪等）
wxc-host-prep.exe prepare-system-drive

# \Device\Null への AppContainer アクセスを設定（起動毎にリセットされるため毎回必要）
wxc-host-prep.exe prepare-null-device

wxc-exec.exe 自体は昇格しません。ホスト準備は必ず wxc-host-prep.exe 経由で行います。

MXC policy JSON の作成

基本原則は次のとおりです。

• デフォルト拒否（Default-Deny）。明示しないフィールドは最も制限的な設定になります。許可したいものだけ宣言します。
• ポリシーは SandboxPolicy（意図を宣言）→ createConfigFromPolicy() → ContainerConfig（backend ごとの具体設定）の 2 段構成です。
• 現行 stable schema は 0.6.0-alpha です。

SandboxPolicy の型定義（一次: docs/sandbox-policy/v1/policy.md）:

type SandboxPolicy = {
  version: string;               // 例: "0.6.0-alpha"
  filesystem?: {
    readwritePaths?: string[];   // 読み書き許可パス
    readonlyPaths?:  string[];   // 読み取り専用パス
    deniedPaths?:    string[];   // 明示的拒否パス（Windows では未対応）
    tempDir?: "shared" | "isolated";
  };
  network?: {
    allowOutbound?:     boolean;
    allowLocalNetwork?: boolean;
    allowedHosts?:      string[];  // Windows では未強制
    blockedHosts?:      string[];  // Windows では未強制
    proxy?: { builtinTestServer: true } | { url: string };
  };
  ui?: {
    allowWindows?:        boolean;        // PowerShell 等の起動に必要
    clipboard?:           "none" | "read" | "write" | "readwrite";
    allowInputInjection?: boolean;
  };
  timeoutMs?: number;
};

network.allowedHosts / network.blockedHosts による host フィルタリングは Windows では現時点で未実装です。Windows でネットワークを制限する場合は ContainerConfig 層の network.defaultPolicy（allow / block）または network.proxy を使います。

policy JSON の最小例を示します。

例 1: ファイルシステム read-only + ネットワーク遮断

{
  "version": "0.6.0-alpha",
  "filesystem": {
    "readonlyPaths": ["C:\\myapp\\src"]
  },
  "network": {
    "allowOutbound": false
  },
  "timeoutMs": 30000
}

例 2: 特定ディレクトリのみ書込許可

{
  "version": "0.6.0-alpha",
  "filesystem": {
    "readonlyPaths": ["C:\\myapp\\src"],
    "readwritePaths": ["C:\\temp\\agent-output"],
    "tempDir": "isolated"
  },
  "network": {
    "allowOutbound": false
  },
  "timeoutMs": 60000
}

clearPolicyOnExit は ContainerConfig（低レベル）側のフィールドです。SandboxPolicy では一時領域の扱いに filesystem.tempDir（shared / isolated）を使います。

利用方法

CLI — native binary での実行

# Windows
wxc-exec.exe config.json                          # ファイルパス指定
wxc-exec.exe --config-base64 <base64-json>        # Base64 エンコード設定
wxc-exec.exe --experimental config.json           # Experimental backend 有効化

# Linux / macOS
./lxc-exec config.json
./mxc-exec-mac --experimental config.json

network.defaultPolicy は ContainerConfig（低レベル）由来のフィールドです。deniedPaths は SandboxPolicy にも存在しますが、Windows では未サポート（Linux/macOS のみ有効）です。

TypeScript SDK での利用

Process Isolation（one-shot / 軽量）— 推奨パス

import {
  spawnSandboxFromConfig,
  createConfigFromPolicy,
  getAvailableToolsPolicy,
  getTemporaryFilesPolicy,
  getPlatformSupport,
} from '@microsoft/mxc-sdk';

if (!getPlatformSupport().isSupported) {
  throw new Error('MXC not available on this host');
}

const tools = getAvailableToolsPolicy(process.env);  // PATH / PYTHONPATH / JAVA_HOME 等
const temp  = getTemporaryFilesPolicy();             // %TEMP% / $TMPDIR

const config = createConfigFromPolicy(
  {
    version: '0.6.0-alpha',
    filesystem: {
      readonlyPaths:  tools.readonlyPaths,
      readwritePaths: temp.readwritePaths,
    },
    network: { allowOutbound: false },
    timeoutMs: 30_000,
  },
  'process',  // containment intent
);

config.process!.commandLine = 'python -c "print(\'hello from sandbox\')"';

const child = spawnSandboxFromConfig(config, { usePty: false });  // pipe モード
child.stdout!.on('data', (d) => process.stdout.write(d));
child.on('close', (code) => console.log('exit:', code));

Session Isolation — state-aware lifecycle（長時間 / agentic ループ向け）

現時点では isolation_session（Windows Insider Preview build 26300.8553 以降）のみ実装済みです。experimental backend のため起動時に experimental フラグを伴います。

import {
  provisionSandbox, startSandbox, execInSandboxAsync, stopSandbox, deprovisionSandbox,
} from '@microsoft/mxc-sdk';

const { sandboxId } = await provisionSandbox('isolation_session');  // 1. プロビジョン
await startSandbox(sandboxId);                                       // 2. 起動

// 3. 複数コマンドを同一サンドボックスで実行
const r1 = await execInSandboxAsync(sandboxId, { process: { commandLine: 'echo hello' } });
const r2 = await execInSandboxAsync(sandboxId, { process: { commandLine: 'whoami' } });
console.log(r1.stdout, r2.stdout);

await stopSandbox(sandboxId);          // 4. 停止 → 解放
await deprovisionSandbox(sandboxId);

Intune での MXC constraints 配布

Intune × MXC の native integration は 2026 年 7 月 preview 予定です。以下は公式ブログに基づく概念で、具体的な Intune ポリシープロファイルの UI/API 仕様は一次未確認です。

1. 開発者が @microsoft/mxc-sdk でエージェントコードに MXC ポリシーを組み込む。
2. IT 管理者が Intune から MXC constraints を組織全体のポリシーとして Windows デバイスに push。
3. Windows が runtime でポリシーを enforce し、エージェント実行時に境界を適用。
4. session isolation ではエージェントに local ID または Entra-backed identity が割り当たり、コンテナ内の全アクティビティがその identity に帰属。

よくある落とし穴

• PowerShell / GUI シェルが起動しない。ui.allowWindows がデフォルト false。PowerShell を使う場合は ui: { allowWindows: true } を明示します。
• Windows でネットワークの host フィルタが効かない。allowedHosts / blockedHosts は Windows 未実装。SandboxPolicy では network.allowOutbound: false で遮断、ContainerConfig 層では network.defaultPolicy: "block" または proxy 経由で制限します。
• Experimental backend が動かない。{ experimental: true } または --experimental が必要です。
• agentic ループで毎回 spawn するとオーバーヘッドが大きい。isolation_session の state-aware lifecycle を使います。

運用

監査・ログ運用

Entra Agent ID の audit/sign-in logs が、現時点で最も詳細な公式スキーマを持ちます。

• agentType による人間/エージェント判別。initiatedBy / targetResources に付与される agentType で判定。notAgentic 以外はエージェント関与を示す。
• blueprintId による相関。どの設計のどのインスタンスが動いたかを後から追える。
• agentSignIn イベント。サインインログに agentSignIn イベント型が追加。
• Entra admin center フィルタ。Sign-in logs で「Agent type」「Is Agent」でフィルタ可能。

GET https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and agent/agentType eq 'AgentIdentity'

/beta エンドポイントは GA 前に変更が入る可能性があります。ここで agentType には 3 つの表現が混在する点に注意してください。①監査ログ enum（agenticApp / agenticAppInstance / agentIdentityBlueprintPrincipal / agentIDuser）、②Entra admin center の UI 表示名（Agent ID user / Agent Identity / Agent Identity Blueprint / Not Agentic）、③上記 Graph sign-in フィルタの wire 値（AgentIdentity 等）です。フィルタの正確な値・構文は /beta 段階につき一次で再確認してください。

Windows 365 for Agents 環境では、次の 4 系統を相関させた end-to-end 監査トレイルを構成できます。

Purview ドキュメントは「すべてのセキュリティコントロールが Entra Agent ID に依存する」と明言します。identity が監査の主キーになる設計です。ローカル MXC 単体の監査ログ API は公式ブログ本文で詳述が確認できず、詳細監査は Entra Agent ID / Purview / Defender 側に集約されます。MXC SDK は --debug フラグで ETW を出します。

権限運用

• 最小権限。MXC はファイル・ネットワーク・UI へのアクセスを JSON ポリシーで宣言し OS がランタイムで強制します。denied paths / network host filtering は Windows 未対応です。
• Conditional Access for Agents。Windows 365 for Agents は CA ポリシーをエージェントの user identity に人間と同等に適用します。リスクに応じて allow / restrict / block を動的評価します。
• Intune 集中管理。MXC constraints を IT 管理者が集中構成・配布します。強制フローは Identity control（Entra）→ Pool assignment（Intune）→ Session establishment（Conditional Access）→ Resource access の順です。

ライフサイクル運用

Foundry hosted agents と Windows 365 for Agents はライフサイクルモデルが異なります。

Windows 365 for Agents では identity がデバイスではなくセッションにバインドされ、セッション間でリセットされます。セッション中は "human can observe the same session in real time and take over control" という監督 UI があります。Agent 365 GA 前に作成されたエージェントは新しい identity primitive を自動継承しないため、Entra Agent ID 付与には再公開が必要です（二次情報: Ragnar Heil）。

ベストプラクティス

反証エビデンスを「誤解 → 反証 → 推奨」で整理します。

多層防御（隔離 + injection 対策 + identity + 監査）

• 誤解: MXC でエージェントを隔離すれば、プロンプトインジェクションも防げる。
• 反証: OS レベルの隔離は damage の封じ込め（blast radius 縮小）には効くものの、injection 自体は防げません。"Sandboxing shrinks the impact radius of a successful prompt injection; it does not prevent the injection itself."（二次情報: SoftwareSeni / digitalapplied）。自然言語入力は正規指示と区別不能で、技術的予防策が存在しません。Microsoft 自身が injection 対策を MXC とは別レイヤ（Defender）に割り当てており、「隔離 ≠ injection 防止」を事実上示します。
• 推奨: 隔離（MXC / コンテナ）+ Defender（injection 検知）+ Entra identity（帰属）+ Purview/監査（事後追跡）の 4 レイヤを組み合わせます。「隔離で injection を防ごうとしない」を設計判断として明示的に記録します。

MXC は現時点で本番のセキュリティ境界にしない

• 誤解: MXC を本番環境のセキュリティ境界として依存できる。
• 反証: microsoft/mxc が「no MXC profiles should be treated as security boundaries currently」「current policies generated by the MXC SDK ... are overly permissive」と明示します。最も強い隔離（microVM / Linux containers / Windows 365 統合）はすべて未出荷のロードマップ段階です。
• 推奨: preview 段階の MXC は多層防御の一部として位置づけ、単独のセキュリティ境界として依存しません。公式警告文を設計ドキュメントに引用して残します。

OS 隔離で過剰権限問題は解けない

• 誤解: OS レベルで隔離すれば過剰権限や confused deputy も解決する。
• 反証: "This is fundamentally an access control and credential delegation problem, not an operating system isolation issue."（SANS）。エージェントが複数ツールの credential を集約すると、個々は最小権限でも aggregate blast radius が許容外になります。Microsoft 自身の Semantic Kernel 研究も "Your LLM is not a security boundary. The tools you expose define your attacker's affected scope." を実証します。
• 推奨: credential はシステム単位で個別に scope を切ります。RFC 8693 act クレームで委譲パスを明示し、「誰の代理で動いているか」を監査ログに刻みます。tool の露出設計を identity/権限設計と同等の優先度でレビューします。

自前基盤では公開標準で同等を組む（ベンダーロックイン回避）

• 誤解: Agent 365 / Entra / Intune / Purview の垂直統合スタックがエージェント統制の唯一解。
• 反証: "lock-in disguised as safety"（二次情報: VentureBeat）。Entra / Intune / Defender / Purview への密結合で非 Microsoft 環境では適用できません。
• 推奨: 自前基盤では公開標準で同じ 4 論点を組みます。

identity を先に立てると監査が後から効きます。Purview が「全セキュリティコントロールが Entra Agent ID に依存」と明言するとおり、自前でも identity レイヤを監査の主キーに据える設計順序を守ります。

責務を混ぜない（隔離 / identity / 委譲 / 監査 を独立レイヤに）

• 誤解: 隔離さえ固めれば identity や監査は後回しでよい。
• 反証: Microsoft 自身が MXC（隔離）/ Entra（identity）/ Purview（監査）を別製品として分離して実装します（意図的な責務分割）。MXC リポジトリには監査・identity 統合の記述がありません。
• 推奨: 4 レイヤを独立して設計・実装し、各々を差し替え可能にします。隔離レイヤ障害が監査レイヤに波及しない設計（監査は隔離の外に置く）にします。identity なき監査（IP/timestamp だけ）は attribution 不能と認識します。

トラブルシューティング

まとめ

Microsoft MXC は、AI エージェントの安全性を「プロンプトで拒否させるか」から「実行環境で何を許すか」へ移す動きを、Windows / WSL の OS レベル実装として具体化しました。ただし公式自身が「現時点でセキュリティ境界として扱うな」と警告するとおり、隔離だけでは不十分で、隔離・identity・委譲・監査を独立レイヤで組む多層防御が要点になります。自前基盤なら Microsoft 製品に縛られず、gVisor / Firecracker / SPIFFE / OAuth2 / RFC 8693 / OpenTelemetry GenAI semconv という公開標準で同じ 4 論点を実装できます。

この記事が少しでも参考になった、あるいは改善点などがあれば、ぜひリアクションやコメント、SNSでのシェアをいただけると励みになります！

参考リンク

• 公式ドキュメント / ブログ
  • Windows platform security for AI agents（Windows Developer Blog, 2026-06-02）
  • Build 2026: Furthering Windows as the trusted platform for development（Windows Developer Blog, 2026-06-02）
  • Microsoft Build 2026: Be yourself at work（The Official Microsoft Blog, 2026-06-02）
  • Hosted agents in Foundry Agent Service (preview)（Microsoft Learn）
  • What is Microsoft Entra Agent ID?（Microsoft Learn）
  • Microsoft Entra Agent ID logs（Microsoft Learn）
  • Identity and security in Windows 365 for Agents（Microsoft Learn）
  • Agent session lifecycle（Microsoft Learn）
  • Use Microsoft Purview to manage Agent 365（Microsoft Learn）
  • When prompts become shells: RCE vulnerabilities in AI agent frameworks（Microsoft Security Blog, 2026-05-07）
• GitHub
  • microsoft/mxc（policy JSON schema 0.6.0-alpha / @microsoft/mxc-sdk）
  • @microsoft/mxc-sdk（npm）
• 公開標準・周辺技術
  • draft-oauth-ai-agents-on-behalf-of-user-00（IETF）
  • RFC 8693 OAuth 2.0 Token Exchange
  • OpenTelemetry GenAI semantic conventions
  • SPIFFE/SPIRE concepts
  • Firecracker vs gVisor（Northflank）
  • Comparing Sandboxing Approaches for AI Agents（Docker Blog）
• 記事（反証・補足）
  • Microsoft launches MXC, an OS-level sandbox for AI agents（VentureBeat）
  • Your AI Agent Is an Easily Confused Deputy（SANS Institute）
  • Confused Deputy Attacks on Autonomous AI Agents（Cloud Security Alliance）
  • Microsoft Agent 365 — What It Can't Do (Yet)（Ragnar Heil）
  • AI Agents in Production — The Sandboxing Problem No One Has Solved（SoftwareSeni）