Kiro CLI の新機能「/sandbox」で、スクリプトとローカル MCP サーバーの通信制限などを試してみた
はじめに
2026-10-13 公開の Kiro CLI 2.31.0 に、/sandbox と /autonomous が追加されました。
公式ドキュメントによると、サンドボックスの対象は、エージェントが実行するシェルコマンドとその子プロセスです。mcpSandboxing を有効にすると、stdio MCP サーバーも対象になります。これらの通信先を、networkAccess の設定で制限できます。
今回は、Linux 環境（bubblewrap 0.12.0、Kiro CLI 2.31.0、V3 セッション）で、パッケージのインストールとローカル MCP サーバーの呼び出しを題材に試しました。
sandbox.json を置いて起動する
Linux では bubblewrap の bwrap が必要です。Kiro CLI は kiro-cli --v3 で起動します。
プロジェクトの .kiro/settings/sandbox.json に次の内容を書いて Kiro CLI を起動すると、ステータス表示に sandboxed と表示されます。
{
"enabled": true,
"networkAccess": "DEFAULT_BLOCKED",
"mcpSandboxing": false
}
networkAccess には DEFAULT_BLOCKED、COMMON_DEPENDENCIES、DEFAULT_ALLOWED を指定できます。DEFAULT_BLOCKED は既定の値で、許可したホスト以外への通信をブロックします。
/sandbox を実行すると設定画面が開きますが、今回は sandbox.json を手で作成し、設定を変えるたびに Kiro CLI を起動し直しました。
インストールスクリプトの通信を制御する
ダミーパッケージを自作しました。インストール時に、HOME への書き込みと、127.0.0.1:18081 で待ち受けているプロセスへの送信を試みます。ローカルのディレクトリから、次のコマンドを Kiro CLI のエージェントに実行させます。
pip install --no-build-isolation --no-deps --target <配置先> <パッケージのディレクトリ>
サンドボックスなしでは、書き込みも送信も成功しました。
21:52:09 STEP2 write outside cwd (HOME): ok
21:52:09 STEP3 send to 127.0.0.1:18081: ok
サンドボックスを有効にし、networkAccess を DEFAULT_BLOCKED にした場合は、どちらもブロックされました。
21:53:50 STEP2 write outside cwd (HOME): FAIL OSError
21:53:50 STEP3 send to 127.0.0.1:18081: FAIL ConnectionRefusedError
ローカルのディレクトリから入れたこのダミーパッケージ自体は、どの設定でもインストールに成功しました。
networkAccess を DEFAULT_ALLOWED にすると送信は成功し、書き込みは DEFAULT_BLOCKED のときと同じくブロックされました。
ローカル MCP サーバーの通信を制御する
標準ライブラリだけで書いたダミーの stdio MCP サーバーを用意しました。ツールを呼ぶと、HOME への書き込み、127.0.0.1:18080 への接続、名前解決を試して結果を返します。プロジェクトの .kiro/settings/mcp.json に次のように登録しました。
{
"mcpServers": {
"probe": {
"command": "python3",
"args": ["/tmp/kiro-sandbox-probe/work/mcp_probe.py"]
}
}
}
mcpSandboxing が false のときは、サンドボックスが有効でも、書き込み、接続、名前解決のすべてが成功しました。次に、sandbox.json の mcpSandboxing を true に変えて Kiro CLI を起動し直しました。
{
"enabled": true,
"networkAccess": "DEFAULT_BLOCKED",
- "mcpSandboxing": false
+ "mcpSandboxing": true
}
すると、3 つともブロックされました。
/autonomous on でもサンドボックスが有効になる
sandbox.json を置いていない状態で /autonomous on を実行すると、ステータス表示に Autonomous と sandboxed が並び、サンドボックスが有効になりました。この状態で curl を実行させると、承認プロンプトは出ず、外部への通信は DEFAULT_BLOCKED のときと同じようにブロックされました。
https://example.com http=000 curl_exit=6 curl: (6) Could not resolve host: example.com
https://pypi.org/simple/ http=000 curl_exit=6 curl: (6) Could not resolve host: pypi.org
通信を許可する
Linux で COMMON_DEPENDENCIES を使うには socat が必要です。socat をインストールしていない環境では、COMMON_DEPENDENCIES にしてもどの通信先にも到達できませんでした。そこで socat 1.8.1.1 を HOME 配下に置いて PATH に通し、networkAccess を COMMON_DEPENDENCIES にして curl を実行しました。
https://example.com http=000 curl_exit=56 curl: (56) CONNECT tunnel failed, response 403
https://github.com http=200 curl_exit=0
https://pypi.org/simple/ http=200 curl_exit=0
https://registry.npmjs.org/ http=200 curl_exit=0
個別のホストは sandbox_network ルールで許可できます。公式ドキュメントによると、DEFAULT_BLOCKED でこの許可ルールを使う場合にも socat が必要です。次は公式ドキュメントのサンプルです。
# ~/.kiro/settings/permissions.yaml
rules:
- capability: sandbox_network
match: ['packages.internal.example.com']
effect: allow
まとめ
Kiro CLI がサンドボックスをサポートし、通信先を制限する手段として利用できるようになりました。
新しいエージェントやツールを Kiro CLI 上で評価するときに、外部への予期せぬ通信を抑えたい場合は、サンドボックスを使えます。そもそも通信が不要なら DEFAULT_BLOCKED、GitHub やパッケージレジストリなど一般的な依存先を許可するなら COMMON_DEPENDENCIES を選びます。どちらの場合も、sandbox_network ルールで特定の通信先を足せます。
ステアリングファイル（.kiro/steering/）でエージェントに方針を指示したうえで、サンドボックスで実行そのものを制限すると、リスクの軽減に役立ちます。お試しください。
