AIエージェント事故オブザーバトリ

パターン詳細

注入された指示による承認ゲート・許可リストの迂回

継続中P3確信度: 中中凡例を見る

注入された指示が、ユーザー確認や実行許可リストといった明示的に用意された制御をすり抜けて、特権的な操作に到達する。指示が通ってしまうこと自体ではなく、用意されていた歯止めが破られている点がこの型の特徴である。

主要な失敗モード

間接プロンプトインジェクション

欠けていた制御

承認ゲートの欠如

対処すべき層

ベンダーの修正

なぜ制御が無かったか

実装上の不具合

最終更新: 2026/09/25

この失敗は何か

このパターンで問題になるのは、指示が届いてしまうことそのものではありません。届いた先に歯止めが用意されていたのに、その横をすり抜けられたことです。

ユーザーに内容を確認させる画面がある。実行できるコマンドを許可リストで絞っている。エージェントが触れる範囲をワークフローの権限で区切っている。いずれも「注入されても致命傷にはならないはず」という設計です。記録されている4件は、その設計が実際には成立していなかった例です。

外部コンテンツに埋め込まれた指示の実行との違いはここにあります。あちらは「データと指示を区別する仕組みがそもそも無い」という設計の性質の話で、パッチでは塞げません。こちらは用意した仕組みに穴があったという話なので、直せます。実際、記録されている4件のうち2件はベンダーが修正版を出しています。

破られた制御の一覧

破られた制御 事例 手口
ワークフローの権限境界 Cline の issue triage から release パイプラインへ 未信頼のissue本文がリリース工程まで到達
エージェントのガードレール全般 IssueTrojanBench 悪意あるissueの**66.5%**が全ガードレールを突破
送信前のユーザー確認 Claude Desktop の claude:// URLスキーム リンクのクリックで確認画面を経ずにプロンプトが自動送信(1.1.2321で修正)
コマンド実行の許可リスト Cursor のオートラン許可リストのバイパス(CVE-2026-22708) シェルビルトインで環境変数を書き換え、承認済みコマンドに別のペイロードを実行させる

最後の事例が、この型の性質をよく表しています。利用者は自分が承認したコマンドが実行されたと認識していますが、実際に走るのは攻撃者が仕込んだ処理です。許可リストは機能しているように見えて、判定の単位が実際の挙動と一致していませんでした。

なぜ影響が大きいのか

業務アシスタントが乗っ取られた場合、被害は原則としてその組織の中に閉じます。ところがリリース工程に到達した場合、汚染された成果物が下流の利用者全員に配布されます。影響範囲が組織の外へ、しかも自動的に広がる点が決定的な違いです。

Cline の事例を重大度S4(重大事故相当)としているのはこのためです。実際の配布被害が確認されたわけではありませんが、成立した場合の影響から評価しています。

IssueTrojanBench の数字も併せて読む価値があります。**66.5%**という突破率は、ガードレールが「たまに破られる」のではなく、現状では機能していないことを示しています。特にGPT系のモデルが脆弱だったと報告されています。

承認ゲートは「ある」だけでは機能しない

権限設計上の落とし穴があります。書類の上では「エージェントに権限を与え、人間が監督する」形になっていても、エージェントが半自律で動く以上、監督は名目になりがちです。人間が実際に一件ずつ内容を確認していないなら、その承認プロセスは存在しないのと同じです。

claude:// の事例は、この問題の極端な形です。確認画面という仕組みは実装されていましたが、特定の経路ではそれを通らずに送信できました。存在する制御が、すべての経路をカバーしているかは、別途確認しないと分かりません。

どこで止められるか

  1. 公開操作を人間の確認必須にする — タグ付け、リリース、パッケージ公開は、エージェントが単独で完了できないようにする。ここだけでも被害の性質が変わります
  2. トークンの権限を落とす — エージェントが使う認証情報から公開権限を外す。運用でカバーするのではなく、技術的に不可能にします
  3. 許可リストは挙動の単位で判定する — コマンド名での照合は、シェルの機能で容易に迂回されます。実際に何が起きるかを見て判定できないなら、許可リストは防御として数えないでください
  4. issue起点の作業をブランチに閉じ込める — 未信頼の入力から始まった作業がmainに直接触れない構造にする
  5. CIの機密情報を分離する — エージェントが起点となるジョブから、署名鍵や公開用トークンに到達できないようにする

当サイトではこの型の「対処すべき層」をベンダーの修正としています。許可リストや確認画面の穴は実装上の不具合であり、直せるものだからです。ただし修正を待つ間は、上の2と5のように権限側で被害範囲を絞るのが確実です。

実務での確認方法

一つ質問を立てるだけで、現状の危険度は概ね測れます。

見知らぬ第三者が「このコマンドを実行してください」と書いたissueを立てたとき、その文章はどこまで到達しうるか。

トリアージのコメントで止まるのか、ブランチが作られるのか、CIが走るのか、公開まで届くのか。エージェントが使うトークンの権限範囲を実際に辿って確認してください。想定より遠くまで届くことが少なくありません。

許可リストを使っている場合は、もう一つ。

許可リストに載せたコマンドが、環境変数やシェルの設定を書き換えられた状態で実行されたとき、何が起きるか。

関連するパターン

関連する事例