MicrosoftはWindows 11で実行コンテナ（MXC）の一般提供を開始し、開発者やIT管理者がAIエージェントによるファイル、ネットワーク、システムリソースへのアクセス範囲を制限できるようにした。この技術は、コードを実行したり、開発ツールを使用したり、ユーザーに代わってタスクを実行したりするエージェントの周囲に、OSが強制する境界を設ける。
10月7日に発表された今回のリリースでは、分離プロセスや個別のWindowsセッションなど、複数の隔離オプションが導入された。ただし、すべての機能が本番利用に対応しているわけではない。MicroVMのサポートは引き続き実験段階で、Microsoft Intuneによる一元管理や、エージェントのID制御の拡張も開発中だ。
Microsoftの発表によると、MXCはエージェント自体から独立してリソース・ポリシーを適用する。AIエージェントは、タスクの遂行に承認済みの境界外の権限が必要になっても、自らに追加のファイルやネットワークへのアクセス権を簡単に付与することはできない。
AIエージェントを導入するセキュリティチームにとって、当面のメリットは、エージェントが生成したコードや自動化ツールが到達できる範囲をより厳密に管理できることだ。組織は適切な隔離レベルを選択し、アクセス・ポリシーを定義したうえで、制限が継続的に適用されていることを確認する必要がある。
Microsoftの実行コンテナはAIエージェントをどう分離するのか
MXCは、ワークロードがアクセスできる対象を定義するため、統一されたJSON構成スキーマとSDKを使用する。開発者は、ファイルの読み書き、ネットワーク接続、プロセス実行、ユーザーのデスクトップとのやり取りを制限できる。
例えばコーディングエージェントには、ソフトウェアリポジトリ内のファイルを変更する権限を与えつつ、本番サーバーの構成変更や従業員の個人文書へのアクセスを禁止できる。
Microsoftは、セキュリティ特性の異なる4種類の隔離バックエンドを挙げている。
- プロセスコンテナ：Windows 11、macOS、Linuxで利用できる。WindowsではAppContainer、macOSではSeatbelt、LinuxではBubblewrapを使用し、軽量なプロセス分離を実現する。
- セッションコンテナ：Windows 11で利用できる。エージェントは別のWindowsアカウントとセッションで実行され、デスクトップ、クリップボード、ユーザーインターフェース、入力が対話中のユーザーから分離される。
- WSLコンテナ：Windows 11で利用できる。Windows Subsystem for Linuxに依存するエージェントツールや開発ワークロード向けに、Linuxの実行環境を提供する。
- MicroVMコンテナ：Windows 11とLinuxで実験的に提供される。より強固な分離を必要とするワークロード向けに、ハードウェア支援型の仮想化を使用する。
適切なバックエンドはワークロードによって異なる。コーディングアシスタントには開発ツールへの応答性の高いアクセスが必要になる一方、機密ファイルを扱うエージェントにはユーザーのセッションからより強力に分離された環境が必要になる可能性がある。
セッション分離は、デスクトップアプリケーションとやり取りするエージェントにとって特に重要だ。エージェントのデスクトップと入力環境をユーザーから分離することで、Windowsは従業員のセッションで動作しているアプリケーションとの意図しないやり取りが起きる可能性を抑えられる。
これらの制御は、より広範なWindows 11のセキュリティモデルを拡張するものだ。Windows 11ではすでに、OSの保護機能によってアプリケーションの権限や機密リソースへのアクセスを制限している。
強制、学習、許可の各モード
MXCには、構成したアクセス制限の動作を決める3つの動作モードがある。
強制モードでは、承認済みポリシーの範囲外の操作をブロックする。承認された操作は実行されるが、定義された境界を越えるリソースへの要求は拒否される。
学習モードでも承認されていない操作はブロックされるが、その内容はJSON形式のアクティビティーレポートに記録される。開発者や管理者はこの情報を使って不足している権限を特定し、隔離を無効にすることなくポリシーを調整できる。
許可モードでは、MXCポリシーによって拒否される操作を記録しつつ、他の適用可能なOSおよび組織の制限に従う範囲で実行を許可する。
この違いはセキュリティチームにとって重要だ。許可モードは、エージェントに必要なリソースを開発者が把握するのに役立つが、構成したMXCの制限を適用するものではない。
組織は、こうした制限が必要な本番ワークロードには強制モードを使用し、許可モードは管理されたポリシーの開発とテストに限定すべきだ。
Microsoftは、エージェント開発者が要求する権限をさらに制限できる、組織向けの制御機能もサポートしている。
ただし、MXCのプロセスコンテナ向けにIntuneでポリシーを一元管理する機能は、まだ一般提供されていない。Microsoftによると、この機能は今後のリリースで追加され、ITチームは管理対象のWindowsデバイス全体でコンテナの作成やリソースへのアクセスを管理できるようになる。
エージェントのIDも開発中の要素だ。Microsoftは、EntraのID機能をMicrosoft Agent 365と統合し、組織がエージェントの活動と従業員の活動を区別したうえで、個々のエージェントに制御を適用できるようにする計画だ。
これらの機能は、現在一般提供されている隔離技術とは別のものだ。
MXCをサポートするAIエージェントと、セキュリティチームが確認すべき事項
Microsoftは、すでにMXCをサポートしているエージェントやフレームワークとして、GitHub Copilot、OpenAI Codex、OpenClaw、Replit、LM Studio、NVIDIA OpenShell、Unsloth AIを挙げている。
Anthropic Claude Code、Box、Egnyte、Manus、Perplexityなど、複数の製品との追加統合も予定されている。
統合をサポートしているからといって、すべてのエージェント機能やデプロイ構成がMXCコンテナ内で動作するとは限らない。組織は、選択したエージェントがサポートする隔離オプションと、権限がどのように適用されるかを確認すべきだ。
この違いは、機密リソースにアクセスできるエージェントを企業で導入する場合に関係する。最近のClaudeエージェントによる本番システムへのアクセスをめぐる懸念は、エージェントが本番環境とやり取りできるようにする前に、運用上の権限を定義しておく必要性を示している。
実行時の隔離にも限界がある。
コンテナは、エージェントが許可されていないファイルを読み取ったり、禁止されたネットワーク宛先に接続したりするのを防げる。しかし、正当にアクセスを許可されたリソースを使って望ましくない操作を実行するよう、エージェントが操られたかどうかを判断することはできない。
例えば、プロンプトインジェクション攻撃によって、承認済みの宛先を通じて情報を開示するようエージェントを誘導される可能性がある。その転送が構成された権限の範囲内であれば、隔離だけでは必ずしも阻止できない。
したがって、AIエージェントを導入する組織は、ツールの認可、機密データへのアクセス、リスクの高い操作に対する人間の承認に関する追加のAIエージェントの安全性制御を導入する必要がある。
MXCを評価するセキュリティチームは、次の4点を優先的に確認すべきだ。
- 適切なバックエンドを選択する。プロセス、セッション、その他のサポート対象となる隔離オプションを、ワークロードの機密性に合わせる。
- 最小権限ポリシーを適用する。必要なファイル、ツール、ネットワーク宛先、ユーザーインターフェースのリソースにのみアクセスを許可する。
- 適用設定を確認する。ポリシーによる制限で未承認の操作をブロックする必要がある場合、本番ワークロードで強制モードが使用されていることを確認する。
- エージェントの動作をテストする。学習モードを使って不足している権限を特定し、予期しないリソース要求を調査し、デプロイ前にポリシーを改善する。
チームは、想定するワークロードでサポートされるWindows構成とMXCバックエンドの要件も確認すべきだ。MicrosoftはOSごとのバックエンドの提供状況を文書化しているが、個々のデプロイに必要な前提条件は異なる可能性がある。
Microsoftの実行コンテナは、AIエージェントにユーザー環境への無制限のアクセスを与えることなく、利用可能なリソースを制限する手段を提供する。本番環境での価値は、組織がこうした境界をどう構成し、ID制御、監視、承認要件とどう組み合わせるかにかかっている。
関連記事：自律型ツールを導入する組織は企業向けAIエージェントを管理し、機密システムへのアクセスを制限する。