10月16日、テクノロジーアナリストのPaul Nashawaty氏（ECI Research所属）が「Kiro Local Sandboxing: OS-Level AI Agent Security」と題した記事を公開した。AmazonのKiro IDEがOSレベルのサンドボックス機能を正式リリースし、AIエージェントが実行するコマンドをカーネル層で制限する仕組みを実装したことについて詳しく解説している。AIエージェントの「信頼問題」に対して、従来のアプリケーション層チェックでは塞げない穴をOSの力で塞ぐという設計思想は、エージェント対応IDE全体の標準を塗り替えうる動きだ。
AIエージェントの「信頼問題」をOSで解く
AIコーディングエージェントが直面する本質的な課題は、能力ではなく信頼だ。開発者はルーティンタスクをエージェントに委ねられるようになったが、その前提は「自分が見ている間だけ動かす」というものだった。複数の並列セッションを走らせ、会議中にビルドを回し、夜間にリファクタリングを実行させる——そうした運用が増えるにつれ、人間の監視は破綻しはじめている。
Kiroのローカルサンドボックスはその問題への直接的な回答だ。コマンドを承認するという行為が、「その先で起きることすべてを信頼する」ではなく、「OSが定めた境界内での実行を許可する」に変わる。アプリケーションが自前で実装したチェックロジックではなく、OSカーネルが強制する境界に依拠することで、エージェントによる迂回の余地を構造的に排除する。
OS標準の仕組みだけで動く
Kiro IDEおよびKiro CLIに正式搭載されたローカルサンドボックスは、コンテナやVMを使わず、OS標準のプリミティブで動作する。
- macOS: Seatbelt（
sandbox-exec） - Linux: bubblewrap
- Windows: AppContainer
これらはいずれも各OSが公式に提供するプロセス分離機構であり、追加ランタイムのインストールを必要としない。重要な設計上の判断として、サンドボックスはエージェントプロセス自体ではなく、エージェントが実行するコマンドのみを囲む。これにより、開発者はセッション途中でも保護のオン・オフを切り替えられ、MCPサーバーを含む既存のローカルツールチェーンはそのまま動作する。開発体験を犠牲にせずにセキュリティ境界を引けるという点が、このアーキテクチャの実用上の強みだ。
二重強制モデルが塞ぐ抜け穴
アーキテクチャ上で最も興味深いのがデュアルエンフォースメント（二重強制）モデルだ。
Kiroにはすでにツール呼び出しレベルのパーミッションチェックが存在する。しかしこれだけでは不十分な場面がある。記事中の例が具体的だ：~/.awsへのread_fileをポリシーエンジンで拒否しても、エージェントが同ファイルを読み込むシェルスクリプトを書いて間接的に実行すれば、アプリケーション層のチェックはすり抜けてしまう。これはツール認可の仕組みが「認識済みのツール経由のリクエスト」しか捕捉できないという、設計上の本質的な限界から生じる。
ローカルサンドボックスはsyscall（システムコール）レベル、つまりカーネル層でこれを遮断する。アプリケーションが何を経由してファイルにアクセスしようとも、最終的にOSへ発行されるシステムコールを検査・制限することで、迂回経路ごと塞ぐ構造だ。
- ツール呼び出しチェック → 認識済みのツール経由のリクエストを捕捉
- カーネルチェック → それ以外のすべてのシステムコールを捕捉
そしてこの二つのポリシーは、既存の**permissions.yaml**に統合されている。ツール認可に使っていた設定ファイルがそのまま二重強制の定義ファイルになるため、設定の乖離（コンフィグドリフト）が起きない。ルールは自動的に両層で適用される。
セキュリティ設計の歴史に照らせば、この構造は「アプリケーションが自前でバリデーションするだけでなく、より低位のレイヤーが強制する」という原則の適用だ。アプリケーション層での検査を信頼の根拠にするのではなく、その下にあるカーネルという、エージェントコードが改ざんできない層に強制を委ねる点が本質的な改善にあたる。
刺さるのはオフライン・規制環境の開発者
この機能が特に効くのは、クラウドサンドボックスを使えない環境だ。記事ではその具体例として以下が挙げられている。
- ネットワーク境界外にデータを出せない規制業種
- VPN内のlocalhostサービス
- ネイティブツールチェーンが必要なiOSビルドなどプラットフォーム固有の開発
ECI Researchの調査（Nashawaty氏が所属するリサーチファームが実施した開発者・IT担当者向け調査）によれば、回答者の46.9%が接続・非接続の混在環境で稼働しており、24.9%がエアギャップ（外部ネットワークから物理的に隔離された）環境で主に作業していると回答している。クラウド専用のサンドボックスでは、そうした開発者の需要に応えられないことは明らかだ。
コンプライアンス面でも意味がある。同調査では、AI開発ツール普及の最大の阻害要因として、回答者の31.8%がFedRAMP/コンプライアンス承認の摩擦を挙げた。セキュリティ強制がアプリケーション層ではなくOSカーネルに移ることで、コンプライアンスチームが持つ根本的な懸念——「AIツールがどこまで触れるか」——に対して構造的な答えを出せる。監査対象となるポリシーの所在がpermissions.yaml一箇所に集約される点も、規制環境での運用を現実的にする要素だ。
また同調査では、政府系テック担当者の49.6%が、今後12ヶ月以内にAIが自組織のコードの26〜50%を生成・補助するようになると予測している。その水準の貢献を実現するには、こうした信頼インフラが前提条件になる。
今後の方向性
現時点でローカルサンドボックスはオプトイン（手動有効化）での提供だが、記事ではこの設定が将来的にワークスペースレベルのデフォルト、さらにはシステム全体のデフォルトへと移行していく可能性が指摘されている。
クラウドサンドボックスですでに使われているネットワークプロキシモデルがローカルセッションにも拡張されたことで、将来的にはより細かいエグレス制御（外向き通信の制御）、プロジェクトタイプに紐づいたドメイン許可リスト、ブロック試行の監査ログなどへの発展経路が開かれている。
GitHub Copilot、Cursor、その他のエージェント対応IDEにとって、OSレベルのセーフティインフラはもはや差別化ポイントではなく調達要件になりつつある、というのが記事全体を貫く見立てだ。カーネル層への強制の委譲という設計判断が、今後のエージェント対応IDEの標準アーキテクチャを定義していく可能性がある。
詳細はKiro Local Sandboxing: OS-Level AI Agent Securityを参照していただきたい。
