Kiro のローカルサンドボックス: エージェントが実行するコマンドを境界内にとどめる

本記事は、2026 年 10 月 14 日に Mike Landi と Doug Clauson が公開した「Local sandboxing in Kiro: keep agent commands within boundaries」を翻訳したものです。

Kiro のローカルサンドボックスは、ローカルのファイルや認証情報を保護する機能です。エージェントが実行するコマンドやスクリプトについて、アクセスできる範囲を制限します。この制限はオペレーティングシステムが強制するため、誤ったコマンドや信頼できないスクリプトによる影響を小さく抑えられます。本機能は、現在 Kiro IDE と Kiro CLI で一般提供中です。

多くのお客様は、Kiro IDE や CLI のエージェントをローカルマシン上で直接実行しています。ローカルで実行すると、エージェントはあなたと同じファイルシステム、インストール済みのツールチェーン、localhost のサービスを参照できます。そのため、エージェントは離れた場所からプロジェクトについて推測する代わりに、実際にビルドしてテストすることが可能です。その代償は、エージェントが実行するすべてのコマンドがあなたの権限を持ち、あなたとして動作することです。コマンドはファイルシステムにもネットワークにもフルアクセスできます。また、オペレーティングシステムのレベルには、エージェントが選んだコマンドとあなた自身が入力したコマンドを区別する仕組みがありません。これまでは、あなたが自分の注意力でこうしたコマンドを制御してきました。セッションを見守り、承認する前に各コマンドを読んで、おかしなものがあれば止めるという方法です。

エージェントを見張る注意力がボトルネックになる理由

エージェントの能力が上がり、開発者が並列で動かすエージェントが増えるにつれて、あなたの注意力がシステム全体のボトルネックになりかねません。タスクが長くなればコマンドが増え、コマンドが増えれば承認疲れが起きます。2 つ目のセッションを始めたり、リファクタリングの途中で席を外したりすると、次のどちらかになります。コマンドがブロックされたまま止まるか、あなたがコマンドを読まなくなるかです。さらに、問題を引き起こすのは悪意のある攻撃者だけではありません。たった 1 回の誤ったツール呼び出しや意図の取り違えが、実際のインシデントにつながる可能性があります。しかも、これまでエージェントが実行できたアクションの範囲は広いものでした。たとえば、Kiro の信頼モデルでは、エージェントが read_file ツールで ~/.aws や ~/.ssh を読み取ることをすでに拒否しています。しかし、粘り強いエージェントがシェル経由でスクリプトを実行すれば、同じファイルを読めてしまう可能性がありました。要求はブロックされても、エージェントは別の方法でファイルを読み取れたのです。IDE、CLI、Web で利用できる Kiro のクラウドサンドボックスは、エージェントを隔離された環境で実行することでこの問題に対処しました。ただし、ローカルにとどめる必要がある作業も数多くあります。たとえば、データレジデンシーの規則によりコードをクラウドに置けない場合や、localhost のサービスや VPN の内側にあるリソースを使う場合です。Xcode と Apple のツールチェーンが必要な iOS ビルドも該当します。

ローカルサンドボックスの仕組み

ローカルサンドボックスでも、エージェント自体はこれまでどおりネイティブに動作します。一方、エージェントがあなたの代わりに実行するコマンドは、カーネルが強制するサンドボックスを経由する仕組みです。使用するサンドボックスは、macOS では Seatbelt、Linux では bubblewrap、Windows では AppContainer です。Kiro のツール呼び出しに対する権限チェックに加えて、オペレーティングシステムがこれらの制限を強制します。サンドボックスに与える権限は、あなたが選べます。たとえば、書き込みできるのはプロジェクトディレクトリと一時領域だけです。カーネルは、よく使われる認証情報のパスの読み取りを拒否します。そのため、エージェントが ~/.ssh/id_rsa を要求しても、判断を挟むまでもなく拒否されます。この拒否は、要求が read_file、シェルのワンライナー、読み取りを代行させるために書かれたスクリプトのどれを経由した場合でも同じです。ネットワークアクセスは、ドメイン単位でフィルタリングするローカルプロキシを必ず経由します。この仕組みは、クラウドサンドボックスですでに使われているモデルと同じです。エージェントはパッケージレジストリなどの承認済みサービスにアクセスでき、それ以外の宛先へのアクセスはブロックされます。

エージェントをサンドボックスの外に置く理由

私たちは、エージェント自体を意図的にサンドボックスの外に置きました。制限されるのはエージェントが実行するコマンドだけです。そのため、セッションの途中でサンドボックスのオンとオフを切り替えたり、セッションを再起動せずにポリシーを変更したりできます。境界を変更しても、次のコマンドをどのようにラップするかが変わるだけだからです。この設計判断から 3 つの利点が得られます。まず、マシンの ID はサンドボックスの中に入りません。マシンの ID とは、エージェントがモデルを呼び出したり Kiro のバックエンドにアクセスしたりするときに使う認証情報です。そのため、サンドボックス内のプロセスが暴走しても、その認証情報を使ってあなたの名義で外部と通信することはできません。次に、ローカルの MCP サーバーはホストのネイティブプロセスとして、変更なしでそのまま動作します。MCP サーバーの動作も制限したい場合は、サンドボックスを経由させることもできます。最後に、従来の意味でのサンドボックスは存在せず、あるのは制限された子プロセスだけです。つまり、サンドボックスに何かを注入する必要もなければ、最初のコマンドを実行する前にコンテナ、イメージ、VM を起動する必要もありません。

サンドボックスによる保護を有効にすると、ローカルでの作業はオペレーティングシステムが強制する制限の範囲内で行われます。リファクタリング、ビルドとテストのループ、依存関係のアップグレードは、これまでどおり手元のマシンで実行されます。ただし、これらの作業で実行されるコマンドがアクセスできるファイルとネットワークの宛先は、制限の対象です。サンドボックスを有効にすると、承認済みのコマンドが実行できる操作を制限できます。

有効化する

現時点では、サンドボックスはデフォルトで無効になっています。ワークスペースで有効にするには、sandbox.json を使用してください。グローバルのデフォルトとして設定する場合は ~/.kiro/settings/sandbox.json に、プロジェクト単位で上書きする場合は <project-root>/.kiro/settings/sandbox.json に配置してください。

{
  "enabled": true
}

ファイルを編集せずに有効にすることもできます。Kiro CLI では、ローカルセッション（kiro-cli chat --v3）で /sandbox on を実行するか、/sandbox を開いてグローバルまたはプロジェクトのスコープとネットワークモードを選択してください。Kiro IDE では、コマンドパレットから Kiro: Open User Sandbox Config (JSON) を実行してください。有効になると、ステータスバーに Command sandbox: Active と表示されます。Windows では、最初に 1 回だけ管理者権限でのセットアップが必要です。IDE ではセットアップを促すプロンプトが表示されます。CLI では /sandbox setup を実行してください。

デフォルトのポリシーを適用するには、ここまでの設定で十分です。デフォルトのポリシーでは、プロジェクトディレクトリへの書き込みが許可され、一般的な認証情報のパスへのアクセスは拒否されます。ネットワークアクセスはローカルプロキシを経由します。エージェントが触れられる範囲を細かく調整したい場合は、permissions.yaml にルールを追加してください。このファイルは、現在すでにツールの認可を管理しているポリシーファイルと同じものです。ローカルサンドボックスは、既存の Workspace Trust モデルとは別に 2 つ目の権限システムを導入するものではありません。同じ fs_read、fs_write、ネットワークに関する capability ルールが、ツールの境界に加えて OS カーネルでも強制されるようになります。以下は ~/.kiro/settings/permissions.yaml の例です。

rules:
  - capability: fs_write
    match: ["./**"]
    effect: allow
  - capability: fs_read
    match: ["~/.aws/**", "~/.ssh/**"]
    effect: deny
  - capability: sandbox_network
    match: ["internal-registry.corp.example.com"]
    effect: allow

Workspace Trust と permissions.yaml でポリシーを設計する

エージェントによる ~/.ssh/id_rsa への read_file ツール呼び出しを拒否するルールは、カーネルレベルでのサンドボックスの読み取りも拒否します。エージェントがそのファイルにたどり着く手段が read_file、シェルのワンライナー、読み取りを代行させるために自分で書いたスクリプトのどれであっても同じです。1 つの信頼ポリシーが 2 回強制されます。1 回目はエージェントがツール呼び出しを通じて行儀よく要求したとき、2 回目は OS がその下で実際のシステムコールをチェックするときです。ツール呼び出しのチェックは必要ですが、それだけでは十分ではありません。ポリシーエンジンが認識しているツールを経由したリクエストしか捕捉できないからです。カーネルのチェックは、前述の Python スクリプトによる回避策を含め、それ以外のリクエストをすべて捕捉します。サンドボックスが読み込むのは、既存のポリシーそのものです。そのため、ポリシーエンジンがすでにサポートしているすべてのスコープ（管理者、ユーザー、ワークスペース、エージェント、セッション）が自動的に引き継がれます。

よくある質問

デフォルトで有効になっていますか？

いいえ。グローバルに有効にするには ~/.kiro/settings/sandbox.json、特定のプロジェクトで有効にするには <project>/.kiro/settings/sandbox.json を使用してください。CLI で /sandbox on を実行するか、IDE のサンドボックス設定から有効にすることもできます。

どのオペレーティングシステムがサポートされていますか？

macOS では Seatbelt を使用します。Linux では bubblewrap を使用します。bubblewrap は socat と一緒に、お使いのディストリビューションのパッケージからインストールしてください。Windows では、1 回限りの管理者権限でのセットアップを行ったうえで AppContainer を使用します。

Kiro が承認を求めなくなるのですか？

いいえ。サンドボックスは、承認済みのコマンドで実行できる操作が制限されています。

ローカルサンドボックスは Kiro IDE と CLI で利用できます。設定の詳細やネットワークモードについては local command sandbox docs を、sandbox_network ルールについては permissions docs を参照してください。

試すには、Kiro IDE 1.3 以降、または Kiro CLI 2.31 以降（ローカルの V3 セッション）にアップデートしてください。

翻訳は Solutions Architect の吉村が担当いたしました。