MXC ポリシーを作成して検証する

MXC ポリシーは、ワークロードがアクセスできる内容を記述します。既定で拒否するアクセス許可から開始し、特定のタスクに必要なリソースのみを追加し、アプリがサポートするすべてのプラットフォームで代表的な入力を使用して結果を検証します。各バックエンドには、ワークロードを開始するために必要なオペレーティングシステムリソースも用意されています。deny-by-default は、プロセスがシステム環境なしで実行されるわけではありません。

ポリシーに関する判断は、信頼できるアプリのコードで行ってください。ツール、プラグイン、スクリプト、AI が生成したコマンドは、必要なリソースを報告できますが、自身でコンテインメントモデルを選択したり、アクセス権限を拡大したりできるようにすべきではありません。

ポリシーと構成を理解する

MXC は、コマンド実行時の設定からリソースのアクセス許可を分離します。

ポリシー設定では、読み取り可能なパス、書き込み可能なパス、ネットワークの接続先、UI へのアクセス、タイムアウトなど、プラットフォームに共通する要件を指定します。
実行設定により、コマンド、作業ディレクトリ、環境、およびコンテナーの選択が追加されます。

V1 SDK では、ContainerRequest はその両方を持ちます。 .NETで、コマンドからContainerRequestを作成し、そのポリシーと実行プロパティを設定し、MxcContainer.RunAsyncまたは spawn API を呼び出します。 TypeScript で、run または spawn 関数に ContainerRequest オブジェクトを渡します。 Rust で、 ContainerRequest 構造体を構築し、 v1::run または spawn 関数に渡します。ワークロードに特定のバックエンドが必要な場合を除き、抽象 Process コンテインメントインテントを優先します。

次の言語に依存しないポリシー設定は、リポジトリスコープのタスクを記述します。ここでは TypeScript の ContainerRequest のプロパティ名を使用しています。.NET では同じ構造で ReadonlyPaths などの PascalCase 形式の名前を使用し、Rust では readonly_paths などの snake_case 形式の名前を使用します。これらの設定だけでは完全な実行要求にはなりません。実行するコマンドや使用するバックエンドが指定されていないためです。これらの設定を調整する前に、必要なディレクトリを作成し、パスを置き換えてください。

{
  "filesystem": {
    "readonlyPaths": ["C:\\src\\my-app"],
    "readwritePaths": ["C:\\src\\mxc-output"],
    "deniedPaths": ["C:\\src\\my-app\\.env"]
  },
  "network": {
    "egress": { "default": "deny" },
    "ingress": { "default": "deny", "hostLoopback": "deny" }
  },
  "ui": {
    "disable": true,
    "clipboard": "none",
    "allowInputInjection": false
  },
  "timeoutMs": 30000
}

要求プロパティを生の実行構成にコピーするのではなく、SDK の型を使用します。図形は異なります。たとえば、要求の timeoutMs は構成の process.timeoutにマップされ、 ui.allowInputInjection は ui.injectionにマップされ、 network.runtimeConfig は最上位の runtimeConfig セクションにマップされます。完全な C#、TypeScript、Rust の例については、 SDK のクイックスタートを参照してください。

互換性のあるスキーマを選択する

次の 3 つの質問を分けてください。

互換性軸	確認すべきこと
SDK と製品リリース	パッケージで提供される API とランタイムコンポーネント
ポリシースキーマ	そのリリースで受け付けられる具体的な構成仕様
ホスト機能	選択した環境が実行時に適用できる制限

MXC 1.0 V1 SDK では、安定した 1.0.0 スキーマが内部的に使用されるため、ContainerRequest でスキーマバージョンを指定しません。スキーマバージョンは、 wxc-exec コマンドラインツールのファイルなど、生の JSON 実行構成を作成する場合にのみ適用されます。

生の構成データでは、登録済みのバージョンを version で正確に指定する必要があります。 MXC 1.0 では、 1.0.0、現在の安定したスキーマ、およびサポートされている最小スキーマである 0.9.0-alphaを受け入れます。 MXC では、欠落しているバージョン、0.9.0-alphaより前の廃止されたバージョン（0.8.0-alphaなど）、未登録のスペル（1.0 や 1.0.1 など）が拒否されます。 1.1.0-alpha開発コントラクトは公開前に変更される可能性があるため、運用環境の構成には使用しないでください。それを選択しても、試験的なバックエンドは有効になりません。

SDK とネイティブランタイムコンポーネントは、同じリリースのものを一緒に保持してください。登録済みコントラクトについては、MXC スキーマのバージョン管理を参照してください。

ファイルへのアクセス範囲を限定する

各パスをワークロードで使用する方法で分類します。

Access	次の目的に使用します
読み取り専用	ワークロードで検査する必要があるが変更しないソース、ツール、ライブラリ、および構成
読み取り/書き込み	タスク固有の出力、キャッシュ、または一時ディレクトリ
拒否する	資格情報、無関係なリポジトリ、機密性の高い構成情報、および広範なアクセス許可の対象範囲内にある、より限定されたパス

実用上可能な限り、アクセスを許可するパスの範囲を限定してください。たとえば、コマンドがテスト出力のみを書き込む場合は、リポジトリルートの代わりにテスト結果ディレクトリを付与します。環境変数、パッケージマネージャー、またはツール検索から検出されたパスを、自動許可ではなく、レビューの候補として扱います。

ワークロードで実際に必要なツールバイナリ、ライブラリ、構成、一時パスを含めます。 SDK はファイルシステム検出ヘルパーを提供しますが、その結果は承認されたポリシーではありません。追加する前に、各候補パスを確認してください。

作業ディレクトリを設定しても、そのディレクトリへのアクセスは許可されません。それを適切なファイルシステムリストに明示的に追加します。

選択したバックエンドでテストしていない限り、パスの範囲が重複するルールに依存しないでください。バックエンドでは異なるファイルアクセスメカニズムが使用され、一部はマップまたはマウントされたディレクトリ内の拒否規則を表すことはできません。

ネットワークアクセスの制御

タスクで必要な場合を除き、ネットワークアクセスを拒否したままにします。選択したバックエンドが適用できるネットワークモデルを選択します。

Model	次の目的に使用します
外部アクセスなし	許可されたローカルリソースのみを必要とする分析または変換
IP/CIDR、プロトコル、およびポート規則を使用した直接アクセス	TCP から既知のサービスエンドポイントへの特定の直接接続を必要とするタスク
アプリケーションによって提供されるプロキシを介した HTTP(S)	プロキシが接続先やアプリケーションレベルのアクセス許可を制御する要求

通信方向別のネットワークポリシーでは、次の通信を区別します。

ワークロードからネットワーク上の接続先への送信通信。
プライベートまたはローカルネットワークからワークロード内のリスナーへのイングレス。
ワークロードとホスト上のサービス間で双方向に行われるホストループバック通信。

IP/CIDR およびポート規則では、アプリケーションプロトコルまたはホスト名は識別されません。 TCP ポート 443 を許可しても、接続で HTTPS が使用されることや、1 つの特定の名前付きサービスにのみ到達することが保証されるわけではありません。ワークロードが接続先の名前解決を直接行う場合は、DNS 要求にもアクセス許可が必要になることがあります。

サポートされているスキーマは、 defaultPolicy、 allowedHosts、 blockedHosts、 network.proxyなど、廃止されたネットワークフィールドを拒否します。代わりに、通信方向を指定する egress フィールドと ingress フィールドを使用してください。ネットワークポリシーの例を参照してください。

カスタムネットワークプロキシを使用する

ホストアプリは、ワークロードを起動する前にプロキシを用意して起動します。 MXC は本番環境用プロキシを提供または管理しません。プロキシは、許可するリクエストと送信先を決定します。MXC は、それを使用するように対応クライアントを構成し、バックエンドのネットワーク制限を適用します。

方向要求では、ネットワークセクションの runtimeConfig.networkProxy 設定を使用して、明示的なポートを持つ HTTP(S) ループバックエンドポイントを識別します。生の実行構成では、この設定は最上位レベルの runtimeConfig.networkProxyです。このエンドポイントはランタイム構成であり、アプリケーション層の許可リストではありません。プロキシモードでは、既定の拒否エグレスが必要であり、直接エグレス許可または拒否規則と組み合わせることはできません。

クライアントの通信経路の設定とアクセス制御の適用は別のものです。プロキシ環境変数またはプラットフォーム設定は、連携する HTTP クライアントが要求を送信する先を指示します。プロキシのみの強制パスでは、インターネットへの直接接続も禁止する必要があります。連携プロキシ構成だけでは、その制限は確立されません。

MXC は、HTTP (S) プロキシを介して SSH、任意の TCP/UDP、またはその他の非 HTTP プロトコルを透過的にリダイレクトしません。ホストループバックとプライベートネットワークの動作もバックエンドによって異なります。同じフラグメントがどこでも機能すると想定するのではなく、カスタムプロキシ構成の例とその前提条件を確認してください。

UI アクセスを制限する

既定では、バックグラウンドワークロードでウィンドウの作成、クリップボードの読み取りまたは書き込み、キーボードとポインターの入力の挿入を許可しないでください。 UI アクセスは、ワークロードの目的のユーザーエクスペリエンスの一部である場合にのみ追加します。

入力インジェクションとは、別のプロセスへの任意のコード挿入ではなく、合成キーボードまたはポインター入力を意味します。

UI コントロールは、ホストとバックエンドに依存します。ランタイムサポート情報を使用して、セキュリティ設計に必要な各制限を確認してください。

バインド実行

所定の時間内に終了するすべてのエージェントアクション、ツール呼び出し、またはスクリプトのタイムアウトを設定します。プロセスには必要な環境変数だけを渡し、シークレットをプロセスの環境変数や読み取り可能なファイルパスに含めないでください。環境変数の指定を省略しても、空の環境が作成されるとは限りません。バックエンドの既定の動作や SDK の環境変数の継承オプションは異なります。

タスクに一致するライフサイクルを選択します。独立したコマンドには、ワンショット実行を使用することを推奨します。状態認識型サンドボックスは、複数のコマンド間でインストール済みのツール、ID、ファイル、またはオペレーティングシステムの状態を共有する必要がある場合にのみ使用してください。

有効なポリシーを検証する

ポリシーをリリースする前に:

SDK のランタイム検出を使用し、選択したバックエンドの前提条件を確認してください。
ポリシーを弱めることなく、構成を作成し、ポリシー検証またはバックエンド利用不可エラーを処理します。
ワークロードで使用することを想定したリソースを使って、代表的な正常系のテストを実行します。
シークレットの読み取り、出力ディレクトリの外部への書き込み、未承認のネットワークパスの使用、または許可されていない UI へのアクセスを試みる否定的なケースを実行します。
学習モードを使用して不足しているアクセス権を調査し、ポリシーを変更する前に各結果を確認します。
学習設定と監査設定をすべて削除し、最後に制限を適用した状態でテストを 1 回実行します。

ホストが必要なコントロールを適用できない場合は失敗します。より広範なアクセス権を持つバックエンドを暗黙的に選択したり、ポリシーフィールドを削除してワークロードを実行したりしないでください。解析または起動が成功したからといって、すべての意図した制限が保持されているわけではありません。

フィードバック

このページはお役に立ちましたか?

最終更新: 2026-11-02