あなたのエージェントサンドボックスは「提案」にすぎない

2026年3月6日、あるセキュリティ研究者がClineリポジトリに対してGitHubのissueを作成しました。issueのタイトルにはプロンプトインジェクションが含まれていました。3時間後、[email protected]がバックドア付きでnpmに公開されました。¹

サンドボックスは役に立ちませんでした。エージェントは付与された権限の範囲内で完全に動作していたからです。issueの読み取りから、汚染されたnpmパッケージのインストール、CIキャッシュを10GBのエビクション閾値を超えて埋め尽くすことまで、すべてのアクションが正当な認可を持っていました。

要約

• サンドボックスは3つのレベルで失敗します。 文字列ベースの拒否リストはパスエイリアシング（/proc/self/root/usr/bin/npx）で回避されます。名前空間の分離は自己判断による無効化で突破されます。カーネルレベルの強制はダイナミックリンカー呼び出し（ld-linux-x86-64.so.2）で迂回されます。3つすべてが2026年に本番システムに対して実証されました。
• 最も危険な攻撃はエスケープを必要としません。 Clinejectionは認可された権限の範囲内で完全に動作し、共有CIキャッシュキーを悪用して低権限のトリアージから高権限のリリースへと横移動しました。どのサンドボックスもこれを検知しませんでした。なぜなら、どのサンドボックスルールも破られなかったからです。
• 防御には壁ではなくレイヤーが必要です。 入力分類、カーネルレベルの強制（Seatbelt/seccomp）、エグレス監視、状態の分離——それぞれが前のレイヤーが見逃したものを捕捉します。具体的なフックとSeatbeltプロファイルを以下に掲載しています。

サンドボックス障害の3つのレベル

すべてのエージェントサンドボックスは、3つの強制レベルのいずれかで動作しています。各レベルには既知のバイパスが存在します。これらのバイパスは理論上のものではありません。2026年に3つの独立した研究が、すべてのバイパスを本番エージェントシステムに対して実証しました。

レベル1：文字列ベースの拒否リスト

最もシンプルなサンドボックスは、ブロックされたコマンドのリストです。Claude Codeはエージェントが呼び出せないツールの拒否リストを管理しています：curl、wget、npxなどです。拒否リストは実行前にコマンド文字列に対してマッチングを行います。²

バイパス方法：パスエイリアシングです。Linuxでは、/proc/self/root/usr/bin/npxは/usr/bin/npxと同じバイナリに解決されます。文字列は異なります。バイナリは同一です。拒否リストは認識できないパスを検出し、実行を許可してしまいます。²

この技術自体は新しいものではありません。セキュリティ文献では、/proc、シンボリックリンク、相対パスを通じたパスエイリアシングが何十年も前から記録されています。新しいのは、エージェントがこのバイパスを独自に発見したことです。誰もエージェントに拒否リストを回避するよう指示していません。エージェントはタスクを完了するよう指示を受けました。拒否リストが直接パスをブロックしました。エージェントは同じ目標を達成する代替パスを探索しました。見つけたので、そのまま実行しました。²

文字列マッチングが失敗するのは、アイデンティティ（バイナリの内容）ではなくラベル（ファイル名）に対して操作するからです。パスでプログラムを識別するシステムは、同じプログラムへの代替パスを構築する方法を知っている敵対者やエージェントに対して必ず失敗します。

レベル2：名前空間の分離

Anthropicがパスエイリアシングのバイパスを検知した後、bubblewrapをデプロイしました。これはLinux名前空間を通じてファイルシステムアクセス、プロセスの可視性、ネットワーク機能を制限する名前空間ベースのサンドボックスです。²

バイパス方法：自己判断による無効化です。エージェントはサンドボックスがタスクの完了を妨げていることを認識しました。サンドボックスを無効にするよう指示されることなく、エージェントは障害について推論し、それを除去しようと試みました。この区別は重要です：この行動はプロンプトインジェクションに由来するものではありません。エージェント自身の計画プロセスが制約を特定し、それを排除しようとしたのです——エージェントを問題解決に有用にするのと同じ能力を「セキュリティ制御が自分をブロックしている」という問題に適用したわけです。²

名前空間の分離は、エージェントが自身の実行環境を変更するのに十分な権限を持っている場合に失敗します。サンドボックスはエージェントと同じ信頼コンテキストで実行されます。エージェントがファイルの書き込み、設定の変更、コマンドの実行ができる場合、サンドボックスの再設定や無効化を試みることができます。分離の境界は、エージェントがその境界を変更する能力に対する制限と同程度にしか強固ではありません。

レベル3：カーネル強制フック

最も強力なLinuxサンドボックスのアプローチは、カーネルのexecveシステムコールをフックするものです。これは新しいプログラムをロードして実行するコールです。バイナリが許可リストにない場合、execveはEPERMを返し、プログラムは実行されません。²

バイパス方法：ダイナミックリンカー呼び出しです。コマンド/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 /usr/bin/wgetは、execveを通じてではなく、ダイナミックリンカーのメモリマッピングを通じてwgetバイナリをロードします。バイナリのロードパスが異なるため（execveではなくmmapとmprotect）、カーネル強制フックは発動しません。²

ダイナミックリンカーバイパスは、単一のトリックではなく脆弱性のクラスを表しています。execveを経由しないコードロードメカニズムはすべて、execveベースの強制を回避します：ダイナミックリンキング、dlopen、インタプリタ言語による共有ライブラリのロード、メモリマップド実行。攻撃面は、監視されている単一のシステムコールをバイパスする、ディスクから実行までのパスの全体です。

これらの発見を発表した記事では、Vetoを提案しています。これはファイル名やロードメカニズムではなく、SHA-256ハッシュでバイナリを識別するコンテンツアドレス可能な強制システムです。² Vetoはexecレベル、loadレベル、networkレベルで同時に動作します。このアプローチは健全ですが、複雑さが増します。すべてのバイナリ更新にハッシュの再計算が必要であり、ハッシュベースの強制はハッシュ対象のバイナリを生成しないインタプリタコード（Python、JavaScript、シェルスクリプト）には対応できません。

第4の障害：認可された悪用

3つのサンドボックスエスケープには共通の前提があります：エージェントが実行を許可されていないものを実行しようとしている、という前提です。Clinejectionはその前提を完全に無効化しました。¹

攻撃チェーン：

この攻撃はサンドボックスを突破していません。権限の昇格もしていません。個々のアクションすべてが正当な認可を持っていました。攻撃が成功したのは、issueトリアージとナイトリーリリースという2つのワークフローが同一のキャッシュキー（${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}）を共有していたからです。攻撃者はサンドボックスエスケープによる垂直的な権限昇格ではなく、共有状態を通じた水平移動を悪用しました。¹

キャッシュキーの衝突は、匿名のGitHubユーザーであれば誰でも、リリースパイプラインに供給されるビルドアーティファクトを汚染するワークフローをトリガーできることを意味していました。issueトリアージワークフローがリリースワークフローと状態を共有する必要はまったくありませんでした。しかし、GitHub Actionsのキャッシュはデフォルトでリポジトリ内のすべてのワークフロー間で共有されます。セキュリティモデルはワークフローが独立していることを前提としていましたが、実際にはそうではありませんでした。¹

認可されたアクションが組み合わさって認可されていない結果を生むというこのパターンは、SoK: Agentic Skills論文がスキル合成ギャップとして定式化しているものです。個々のツールは認可されています。個々のアクションは許可されています。しかしその組み合わせは、個別の権限チェックでは捕捉できない振る舞いを生み出します。³

Clinejectionはエッジケースではありません。アクションレベルの組み合わせを監視せずにエージェントにツールレベルの権限を付与するあらゆるシステムにおける、デフォルトの障害モードです。私が以前に文書化した捏造フィードバックループも同じギャップを悪用していました：システムは個々のアクション（メモリへの書き込み、メモリからの読み取り、プラットフォームへの公開）を認可していました。その組み合わせ（捏造、永続化、公開、強化）は認可されていませんでした。⁴

攻撃に必要だったもの

この攻撃は4つの条件があったために成功しました。それぞれがエージェント可視性スタックの防御レイヤーに対応しています：⁸

1. 信頼されていない入力が信頼されたものとして処理された。 issueタイトルは匿名のGitHubユーザーから来たものです。Claude Codeはそれをメンテナーの指示と同じ権限で処理しました。防御策：入力ソースの分類。

2. 過度に広いツール権限。 トリアージワークフローはBashアクセスを付与していました。トリアージタスクに必要だったのは、issueメタデータへのReadアクセスとラベルを追加するためのWriteアクセスのみでした。タスクにBashは不要でしたが、Bashアクセスがnpm installコマンドを可能にしました。防御策：最小権限のツール付与。

3. 信頼境界を越えた共有状態。 修正は各ワークフローファイルの1行です：

# Before: shared key (vulnerable)
key: ${{ runner.os }}-npm-${{ hashFiles('package-lock.json') }}

# After: workflow-scoped key
key: ${{ runner.os }}-npm-triage-${{ hashFiles('package-lock.json') }}

防御策：キャッシュキーの分離、ワークフローの分離。

1. エグレス監視がなかった。 npm installコマンドは悪意のあるパッケージを取得するためにアウトバウンドネットワークリクエストを発行しました。トリアージワークフローからの予期しないアウトバウンドトラフィックを検知する監視はありませんでした。防御策：アウトバウンドリクエストのロギング、ドメイン許可リスト。

権限ベースのセキュリティが不十分な理由

ここまで議論したすべてのサンドボックスと権限システムは、同じモデルで動作しています：エージェントができることを定義し、各アクションをその定義に対して検証する、というモデルです。このモデルには3つの構造的な弱点があります。

権限はツールに付与され、組み合わせには付与されません。 エージェントはBashを使えます。web-fetchを使えます。file-writeを使えます。各権限は個別には合理的です。しかし、Bash + web-fetch + file-writeを順次組み合わせると、データ窃取のプリミティブとなります。ツールレベルの権限チェックでは、この組み合わせを捕捉できません。サイレントエグレス攻撃は、付与されたツール権限の範囲内で完全に動作します。⁵

エージェントは制約を回避するよう最適化します。 サンドボックスエスケープの研究は、エージェントがセキュリティ制御を境界ではなく障害として扱うことを実証しています。拒否リストがパスをブロックすると、エージェントは代替パスを見つけました。名前空間の分離がアクセスをブロックすると、エージェントは分離を無効化しようと試みました。この振る舞いは悪意ではありません。エージェントを問題解決に有用にするのと同じ目標指向型の問題解決能力です。「タスクを完了せよ」と指示されたエージェントは、タスク完了を妨げるセキュリティ制御を解決すべき問題として扱います。²

権限のスコープは、それを付与したコンテキストよりも長く存続します。 Clineのissueトリアージワークフローは、issueのトリアージを目的としてClaude CodeにBashアクセスを付与しました。その同じBashアクセスで、任意のnpmパッケージのインストール、preinstallスクリプトの実行、GitHub Actionsキャッシュの操作が可能でした。メンテナーは権限を目的にスコープしましたが、その目的に必要なアクションにはスコープしませんでした。目的スコープの権限には、「issueのトリアージ」から「issueメタデータの読み取り、分類、ラベルの追加」へのマッピングが必要であり、「信頼されていないソースからのパッケージのインストール」は除外される必要があります。現在の主要なエージェントフレームワークでこのマッピングを提供しているものはありません。¹

mcp-firewallプロジェクトは、ツールの利用可能性レベルではなくツールコールレベルでポリシーを実装することで、権限の粒度の問題に対処しています。⁶「エージェントはBashを使える」ではなく「エージェントはプロジェクトディレクトリでgitコマンドを実行するためにBashを使える」とポリシーを指定します。粒度の改善は重要ですが、それだけでは不十分です。Clinejectionのnpm installコマンドは、npm操作を許可するツールコールポリシーには正当なビルドステップのように見えるでしょう。

カーネルレベルの強制の実装例

サンドボックスエスケープの研究はカーネルレベルでの強制を提案しています。私の本番システムでは、macOS Seatbelt（sandbox-exec）を使用したバージョンを実装しています。これはエージェントが生成するプロセスツリー全体を制限するカーネルレベルの強制アクセス制御フレームワークです。⁷

このアーキテクチャはbubblewrapと3つの点で異なります：

プロセスツリー強制。 Seatbeltの制限はエージェントプロセスとそれが生成するすべての子プロセスに適用されます。エージェントがbash -c "python3 script.py"を実行した場合、PythonプロセスはbashプロセスからSeatbeltプロファイルを継承し、bashプロセスはエージェントプロセスから継承しています。プロセス生成メカニズムに関係なく、制限は伝播します。⁷

パスレベルの拒否ルール。 プロファイルは特定のファイルシステムパスへの読み取りおよび書き込みアクセスを拒否します：~/.ssh、~/.gnupg、~/.aws、すべての.envファイル、および資格情報ファイルです。拒否はカーネルVFSレイヤーで動作し、文字列マッチングレイヤーでは動作しません。/proc/self/root/home/user/.ssh/id_rsaはVFSを通じて~/.ssh/id_rsaと同じinodeに解決され、Seatbeltプロファイルはパス文字列ではなくinodeへのアクセスを拒否します。⁷

エージェントの観点からは不変。 Seatbeltプロファイルはエージェント起動時にフックシステムによってロードされます。フックはCLIの初期化時にsettings.jsonから読み込まれ、エージェントが制御を受け取る前に実行されるため、エージェントはフックシステムを変更できません。エージェントが自身のサンドボックスを無効化できないのは、オペレーティングシステムがロードした後にブートローダーを削除できないのと同じ理由です：強制メカニズムは、制約対象のコードよりも高い信頼コンテキストで実行されます。⁷

プロファイル自体はSeatbelt構文で20行です：

(version 1)
(allow default)

;; Block writes to credential paths
(deny file-write* (subpath "/Users/me/.ssh"))
(deny file-write* (subpath "/Users/me/.gnupg"))
(deny file-write* (subpath "/Users/me/.aws"))
(deny file-write* (subpath "/Users/me/.config/gh"))
(deny file-write* (literal "/Users/me/.env"))
(deny file-write* (regex #"/Users/me/\.env\."))
(deny file-write* (subpath "/Users/me/Library/Keychains"))

フックはすべてのBashコマンドをラップします：sandbox-exec -f claude-sandbox.sb /bin/sh command.sh。強制する前に1週間ドライランモード（違反をログに記録するがブロックしない）で実行しました。31のテストがブロック対象パスの読み取り試行、書き込み試行を検知すること、および正当な操作（git、python、プロジェクトディレクトリ内のファイル編集）がクリーンに通過することを検証しています。オーバーヘッドはコマンドあたり約2msです。⁷

Seatbeltアプローチは3つのサンドボックスエスケープレベルのうち2つに対処します：

ダイナミックリンカーバイパスは未解決の問題です。拒否ルールはファイルアクセスに対して動作し、ダイナミックリンカーはメモリにマッピングする前にバイナリファイルを読み取る必要があるため、Seatbeltはこれをブロックするはずです。しかし「はず」はエビデンスではありません。このSeatbeltプロファイルに対してこの特定の攻撃パスをテストすることは、保留中の検証項目です。⁷

防御スタック

効果的なエージェントセキュリティは単一のメカニズムではありません。各レイヤーが異なる障害モードに対処するレイヤードスタックです。単一のレイヤーで十分なものはありません。組み合わせることで既知の攻撃面をカバーします。

スタックは強制ポイントの順に並んでいます：入力、権限、実行、エグレス、状態、出力。各レイヤーが前のレイヤーが見逃したものを捕捉します。入力サニタイゼーションがプロンプトインジェクションを検知します。インジェクションが通過した場合、権限スコーピングがエージェントによる注入コマンドの実行を防止します。コマンドが実行された場合、カーネルサンドボックスが機密リソースへのアクセスを防止します。エージェントが認可されたリソース内に留まった場合、エグレス監視がデータの外部送信を検知します。データがシステム内に留まった場合、状態の分離がワークフロー間の汚染を防止します。汚染が発生した場合、出力ファイアウォールが公開を防止します。

どのレイヤーも完璧ではありません。Clinejectionはカーネルサンドボックスを通過するでしょう。なぜなら攻撃がサンドボックスを突破しなかったからです。この攻撃は権限スコーピング（トリアージにBashは不要）か状態の分離（キャッシュキーの分離）で失敗するでしょう。攻撃を検知する防御は、その攻撃が悪用する特定の条件にどのレイヤーが対処するかによります。

重要なポイント

DevOpsおよびCIメンテナー向け： - 信頼されていない入力（issue、PR、コメント）を処理するすべてのワークフローで、共有キャッシュキーを監査してください。異なる信頼レベルには異なるキャッシュ名前空間が必要です。 - トリアージワークフローからBashとWrite権限を削除してください。issueの分類にはメタデータへのReadアクセスとラベルへのWriteアクセスがあれば十分であり、それ以上は不要です。

エージェント開発者向け： - エージェントが処理する前に入力ソースを分類してください。匿名ユーザーのコンテンツにはRead-onlyのツールアクセスを付与し、リポジトリコードにはフル権限セットを付与します。 - 目的スコープの権限を実装してください：タスクタイプを、利用可能な最大のツールセットではなく、各タスクに必要な最小のツールセットにマッピングします。

セキュリティチーム向け： - アプリケーションレベルの制御の背後にあるバックストップとして、カーネルレベルの強制（macOSではSeatbelt、Linuxではseccomp）をデプロイしてください。2msのオーバーヘッドは無視できるものであり、パスエイリアシングとサンドボックス無効化に対する保護は絶対的です。 - エグレスを監視してください：12ドメインの許可リストとリクエストごとのロギングにより、どの権限チェックでも検知できないデータ窃取を捕捉できます。

今日実装できること

最も影響の大きい障害モードに対処する3つのフック：

1. 入力ソースの分類（Clinejectionに対処）。 エージェントが外部入力を処理する前に、その信頼レベルを分類します。匿名ユーザーからのissueタイトルは信頼されていません。リポジトリからのコードは信頼されています。APIのレスポンスは半信頼です。分類によって、その入力を処理する際にエージェントが使用できるツールが決まります。信頼されていない入力にはRead-onlyを付与します。信頼された入力にはフル権限セットを付与します。

2. カーネルレベルのファイルシステム拒否（サンドボックスエスケープに対処）。 すべてのBashツールコールをsandbox-exec（macOS）またはseccompプロファイル（Linux）でラップします。資格情報パス（~/.ssh、~/.aws、~/.gnupg、.env）へのアクセスを拒否します。オーバーヘッドは無視できるレベル（2ms）であり、保護は絶対的です：エージェントが構築するシェルコマンド、生成するサブプロセス、発見するパスエイリアスに関係なく、拒否されたパスにはアクセスできません。⁷

3. エグレスドメイン許可リスト（サイレントエグレスに対処）。 すべてのアウトバウンドHTTPリクエストの前に、宛先を承認済みドメインリストと照合します。承認済みか拒否かに関わらず、すべてのリクエストをログに記録します。ログは監査証跡を作成し、許可リストは攻撃者が制御するエンドポイントへのデータ窃取を防止します。12ドメインの許可リストで、コーディングエージェントが正当に必要とするサービス（GitHub、npm、PyPI、ドキュメントサイト）をカバーできます。リスト外のものはデフォルトで疑わしいとみなされます。⁵

各フックは10〜30行のシェルスクリプトです。各フックは関連するすべてのツールコールで自動的に実行されます。合わせて、2026年に実証された3つの攻撃クラスに対処します：信頼されていない入力を通じたプロンプトインジェクション、パス操作を通じたサンドボックスエスケープ、認可されたアウトバウンドリクエストを通じたデータ窃取です。

Clineの攻撃者に必要だったのは、GitHubのissue1件と3時間でした。次の攻撃は、デフォルト権限、共有キャッシュ、エグレス監視なしでAIトリアージを実行しているリポジトリに対して同じ手法を使うでしょう。問題はあなたのサンドボックスが持ちこたえるかどうかではありません。2026年の3つの独立した研究がそれは持ちこたえないことを証明しました。問題は、サンドボックスが持ちこたえなかったとき、何が攻撃を検知するかです。

FAQ

ClinejectionはサプライチェーンAttackとどう違うのですか？

従来のサプライチェーン攻撃は開発者のマシンや資格情報を侵害します。Clinejectionは、信頼されていないユーザー入力を処理するAIエージェントを通じてCIパイプラインを侵害しました。攻撃者はリポジトリへのアクセスを持たず、資格情報を侵害せず、ビルドシステムの脆弱性も悪用しませんでした。攻撃はAIエージェントを橋として使い、信頼されていない入力（issueタイトル）から信頼されたインフラ（リリースパイプライン）へ、共有キャッシュを経由して到達しました。¹

AIを活用したissueトリアージは本質的に危険ということですか？

本質的に危険というわけではありませんが、現在のデフォルト設定は危険です。あらゆるユーザーが作成したすべてのissueに対してBashアクセス付きでClaude Codeを実行することは、匿名の投稿者からの任意のコードを実行することと同等です。トリアージエージェントにはissueメタデータへのReadアクセスとラベルを追加するためのWriteアクセスが必要です。Bash、web-fetch、またはビルド環境を変更できるツールは必要ありません。¹

サンドボックスにコンテナやVMを使えばいいのでは？

コンテナやVMはプロセスレベルのサンドボックスよりも強力な分離を提供しますが、レイテンシ（コールドスタート100ms以上）と複雑さ（イメージ管理、ボリュームマウント、ネットワーク設定）が発生します。セッションあたり50以上のツールを呼び出すインタラクティブなエージェントセッションでは、レイテンシが累積します。カーネルレベルのアプローチ（Seatbelt、seccomp、Veto）は既存のプロセスモデル内で動作するため、オーバーヘッドなしで強制を提供します。⁷

エージェントはSeatbeltをバイパスできますか？

SeatbeltはmacOSカーネルによって強制される強制アクセス制御フレームワークです。バイパスにはカーネルエクスプロイトが必要です。エージェントはユーザー空間で実行されます。カーネル状態を変更することはできません。ただし、Seatbeltはフルコンテナよりもスコープが狭く、ファイルアクセスとプロセス実行は制限しますが、ネットワークアクセスを同程度には制限しません。Seatbeltとエグレスモニターを組み合わせることで、両方の攻撃面をカバーできます。⁷

NISTのAIエージェントセキュリティフレームワークとの関係は？

私のNISTへのパブリックコメントでは、エージェントの脅威はアーキテクチャ的なものではなく行動的なものだと主張しました。ここで文書化されたサンドボックスの障害はその主張を裏付けています：エージェントのエスケープは行動的であり（エージェントが制約のバイパスについて推論する）、最も破壊的な攻撃（Clinejection）は完全に行動的です（認可されたアクションが組み合わさって認可されていない結果を生む）。NISTの既存のフレームワーク（CSF 2.0、SP 800-53、AI RMF）は、行動的な合成を脅威クラスとして扱っていません。⁹