プルリクエストが提出され、その説明欄には整った不具合報告が書かれています。人間より先にボットがそれを読み込み、いくつかのシェルコマンドを抽出して承認を得ると、その実行結果をスレッドに投稿します。メンテナーが一連のやり取り全体に目を通すのは、翌朝になってからです。
Novee Securityの創業エンジニアであるElad Meged氏は、この一連の流れを3社のベンダー自身のリポジトリに対して、各社がデフォルトで提供している設定のまま試してみました。その結果、Anthropicのパイプラインは機密情報を渡してしまいました。これらのエージェントのいずれかを初期設定のまま運用している組織は、すべて同様のリスクを抱えていることになります。
エージェントとは、モデルとハーネスの組み合わせです。モデルが意図を生成し、ハーネスがその意図をシェルコマンドやファイル読み取り、API呼び出し、ネットワークリクエストへと変換します。そして、承認ロジック、ツールの権限設定、パス制限、出力の取り扱いを担うのもハーネスです。人がステップごとに確認しないワークフローでは、このハーネスがセキュリティ上の境界線となります。
Meged氏はNoveeで自動ペネトレーションテスト用のAIエージェントを構築しており、同じ攻撃的な手法をエージェント自身に対して逆手に取って適用しました。
「いずれのケースでも、プロンプトインジェクションは単なる配送手段に過ぎませんでした。実際の脆弱性は、ハーネスがどのように信頼判断を下し、それらの判断が各段階をまたいでどう組み合わさるかという点にありました。コマンドは安全に見えるから承認されます。出力はそれがデフォルトの挙動だから公開されます。どちらの判断も単体では誤りではありません。しかし両者が組み合わさると、情報流出の連鎖になってしまいます。プロンプト層だけを監視していては、ある『安全』な判断が次の判断に引き継がれる、その受け渡しの瞬間を決して見ることができません」とMeged氏はHelp Net Securityに語りました。
パッチのたびに新たな境界線が引かれた
Meged氏はanthropics/claude-codeのデフォルトワークフロー設定であるClaude Code Actionに対して複数の脆弱性を報告しました。このパッケージは数百万人が利用しています。
「私たちが脆弱性を報告するとパッチが当てられ、そのパッチを当てる過程で『何を安全とみなすか』という境界線が引き直されました。パッチそのものが、境界線がどこに移動したかを示してくれるので、次にどこを調べればよいかが正確にわかったのです」と同氏は述べています。
Anthropicは各ラウンドで報奨金を支払いました。
「強調しておきたいのは、彼らの修正が不十分だったり、いい加減だったりしたわけではないということです。Anthropicはあのパイプラインで数十ものチェックを実行しており、各パッチはその特定の穴をきちんと塞いでいました。しかし問題は、ラウンドを重ねるごとに攻撃の検出が難しくなっていったことです。最終ラウンドでは、それ以前のすべての修正をくぐり抜けるチャネルを通じて機密情報を取得できてしまいました。攻撃者への外向き通信もなく、書き込みもなく、ログも残らない形でです」とMeged氏は語りました。
Anthropicは全ラウンドで報奨金を支払った
「バグ報奨金というのは、『これが特定の不具合で、これだけの価値がある』という形で範囲を限定して報いるものです。そのため、ベンダーはラウンドを重ねるごとに気前よく支払いを続けながらも、それぞれを個別の事案として扱うことができてしまいます」とMeged氏は述べています。
「公平を期すために言えば、報奨金を支払うこと自体は正しい判断ですし、私たちも丁重に扱ってもらいました。ですから、これに悪意を読み取っているわけではありません。しかし、同じ研究者が異なる角度から同じアーキテクチャ上の継ぎ目を繰り返し破り、修正のたびに境界線が次の攻撃対象へと移動するだけだとすれば、『バイパス1件につき報奨金』というモデルは、実はゆがんだシグナルを生み出してしまいます。つまり『これはもう解決済みだ』というメッセージを発してしまうのに、根本的な脆弱性は解消されていないのです。だからこそ、この問題をどう表現するかが重要になります。Googleは自社の対応を『信頼モデルの更新』と呼びましたが、これはこの問題を構造的な問題として的確に名付けています」。
GoogleのアドバイザリはCVSS 10.0を記録
Gemini CLIはgoogle-gemini/gemini-cliというリポジトリ上で動作しており、10万を超えるスターを獲得しています。Meged氏は、信頼できない入力を処理するCIワークフロー向けにGoogleのドキュメントが推奨しているセキュリティ設定を用いて、そこでも同様の攻撃連鎖を実証しました。運用者が設定していたはずの制限が、実行時点では適用されていませんでした。
この脆弱性はGHSA-wpqr-6v78-jr5gの一部として公表されました。深刻度はCVSSスケールの最高値に位置づけられています。
OpenAIのサンドボックスは、把握している経路しか保護しない
Codex CLIは、すべてのデプロイメントにデフォルトのサンドボックスを備えています。ワークスペースを共有する複数段階のワークフローでは、ある段階で書き込まれた状態が、次の段階では信頼できるコンテキストとして扱われてしまいます。保護対象パスのリストは、「何を保護すべきか」についての一連の前提の上に成り立っています。
Anthropicはパイプラインに何層ものチェックを組み込み、Googleは環境のサニタイズを伴う複数の実行モードを構築し、OpenAIは保護対象パスを備えたサンドボックスを構築しました。防御機構はそれぞれ存在します。しかし、それらは受け渡しの部分で破綻してしまうのです。
ベンダーは表面的なパッチを当て続けている
「構造的な修正とは、ラベルを鵜呑みにするのをやめ、判断の時点だけでなく、消費される時点でも信頼性を再検証することを意味します。現状のハーネスは『このコマンドは読み取り専用だ』『このドメインは事前承認済みだ』といった安全性の判断を早い段階で一度下すだけで、後続のコンポーネントはその文脈で本当にその判断が成り立つかを確認しないまま、その判断を引き継いでしまいます。読み取り専用のコマンドであっても、その出力が公開チャネルに流れ込むのであれば、実質的には読み取り専用とは言えません。事前承認済みのドメインであっても、攻撃者が操作したコンテンツを配信しているのであれば、実際には安全ではないのです」とMeged氏は述べています。
「単一のベンダーが意味のある改善を実現することは十分にあり得ますし、実際、私たちの報告を受けて既にそうしたベンダーもあります。しかし、私たちが検証した3社すべてでこのパターンが繰り返されていることは、業界全体でエージェント用ハーネスが構築される際に、共通のアーキテクチャ上の前提が存在することを示唆しています。これに正式な標準が必要なのか、あるいは失敗のパターンについての共通理解があれば十分なのかはともかく、この議論は一つのセキュリティチームの中だけでなく、ベンダー間で行われる必要があります」。
Meged氏はBlack Hat USA 2026で、コードレベルの分析結果とライブデモンストレーションを発表する予定です。
今週、点検すべきこと
Meged氏は、現在本番環境でこうしたエージェントを運用しているチームに向けて、一つの点検項目を挙げています。
「エージェントの出力、あるいはエージェントが影響を及ぼし得るあらゆる状態が、異なる権限を持つ後続の段階でどこで消費されているか、その経路をすべて追跡してください。ハーネスが『これは安全だ』と判断している箇所を見つけ、そのうえで問い直してください。その出力はその後どうなるのか。公開されるのか。設定として読み込まれるのか。承認時に想定していたよりも広い権限を持つツールに渡されるのか。
「多くのチームは、エージェントに何ができるかを監査しています。しかし、私たちが繰り返し見つけているリスクは、その『後』に起きること、つまり『承認』と『実行』の間、『読み取り』と『公開』の間、『取得』と『信頼』の間の受け渡しの部分にあるのです」。
翻訳元: https://www.helpnetsecurity.com/2026/07/29/ai-agent-security-safety-check/
