侵害されたAIエージェントを捕捉するための5つのランタイムシグナル

2025年6月、「プロンプトインジェクション」という用語を生み出したエンジニア、Simon Willisonがセキュリティコミュニティで広く話題となった警告を発表しました。彼がそれを「致死的トリフェクタ」と呼んだのは、単一のAIエージェントに組み合わさることで間接プロンプトインジェクションによる悪用への道をほぼ確実に開いてしまう3つの能力——プライベートデータへのアクセス、信頼できないコンテンツへの露出、そして外部への通信能力——を指してのことです。

この枠組みは明快で実用的なものでした。エージェントがメールを読み取り、任意のウェブコンテンツを取り込み、外部へのリクエストを送信できる場合、そのコンテンツパイプラインのどこかに悪意のある指示を埋め込んだ攻撃者は、ユーザーが気づかないうちにエージェントにデータを外部へ持ち出させることができます。Willisonはこの点を裏付けるべく、実際の本番環境での悪用事例を長いリストで示しています。Microsoft 365 Copilot、GitHubのMCPサーバー、GitLab Duo、Slack AI、Google Bard、Amazon Qなど、同じ種類の攻撃が繰り返されているのです。

当時はエージェントの用途が概して限定的だったため、このトリフェクタはシグナルとして機能していました。致死的トリフェクタの要素のうち1つか2つしか実行できないエージェントは、リスクが低いと評価できたのです。この組み合わせを避けることは、実行可能な設計戦略のように思えました。

しかし、今日の実務者が展開するものを見れば、その余地はすでに閉じられています。顧客向けサポートエージェントはチケット履歴や顧客レコードを読み取り、ユーザーメッセージや添付ファイルを取り込み、CRMや返金API、チケット管理システムを呼び出します。メールAIは受信トレイとカレンダーを読み取り、見知らぬ人からの受信メッセージを処理し、ユーザーに代わって返信を送信します。

これらはエッジケースや設計の拙いデプロイではなく、企業や個人が実際に求めているエージェントであり、ベンダーが目指して構築しているものです。

デフォルト設定となった致死的トリフェクタ

SophosのCISOであるRoss McKercharは、今年5月に公開した記事の中でこう端的に述べています。「実務者が実際に求める能力（データの読み取り、外部コンテキストの理解、アクションの実行）は、確実に危険な領域へと踏み込む。これは設定ミスではなく、有用性のためのアーキテクチャ上のコストだ」と。その通りです。プライベートデータへのアクセスがないエージェントは役に立たず、外部コンテンツを処理できないエージェントは孤立した存在であり、外部と通信できないエージェントは何もできません。トリフェクタの要素を一つでも取り除けば、エージェントではなく検索ボックスに近いものになってしまいます。

正当なエージェントアーキテクチャのすべてがトリフェクタの3つの特性をすべて持つとすれば、トリフェクタはもはやリスク上昇の有意な指標ではありません。それはデフォルトの設定なのです。これを危険信号として扱うことは、DNS解決をネットワーク侵害のシグナルとして扱うようなものです。一部の脅威モデルでは技術的に正しいとも言えますが、実際のあらゆるデプロイに普遍的に存在するものです。

McKercharの記事は、対応策を「爆発半径の縮小」として位置づけています。これは合理的な運用哲学ですが、トリフェクタを防止可能なものではなく、所与の条件として受け入れるものです。それは妥当な判断です。問題は、受け入れた後に何をするかということです。

Metaのセキュリティチームは、逆方向から同じ結論に達しました。2025年10月、彼らは「Rule of Two（2の法則）」を発表しました。これは、エージェントが1つのセッションでトリフェクタの3つの特性のうち最大2つしか満たさないことを推奨するフレームワークであり、3つすべてが必要な場合はヒューマン・イン・ザ・ループの承認を必要とします。Willison自身もこのフレームワークを支持しており、「今日のセキュアなLLM搭載エージェントシステムを構築するための最良の実践的アドバイス」と評しています。

ただし、Metaの制限事項のセクションでは、多くの望ましいユースケースがこのフレームワークにうまく収まらないこと、また「エージェントのRule of Twoを満たす設計でも、依然として失敗しやすい可能性がある」と認めています。これはフレームワークへの批判ではなく、問題がアーキテクチャレベルの解決策を超えてしまったことの確認です。

露出の規模はもはや理論上のものではありません。Googleが2026年4月にCommon Crawlリポジトリを調査したところ、公開ウェブページ全体にわたってプロンプトインジェクションの試みが発見されました。その内容はいたずら的なものからデータ窃取ペイロードまで多岐にわたり、悪意のある試みは2025年11月から2026年2月にかけて32%増加しています。Googleは現時点では巧妙さはまだ低いとしながらも、このトレンドを攻撃者の関心が成熟しつつあるシグナルとして指摘しています。

トリフェクタが警告していた環境は、すでに到来しています。

侵害されたエージェントの検出方法

トリフェクタがほぼすべてのデプロイ済みエージェントに当てはまるとすれば、実務者はトリフェクタを有するシステム内で、侵害された動作を通常の動作と区別するシグナルを必要としています。それはアーキテクチャレベルの評価から、ランタイムの振る舞いによる検出へと軸足を移すことを意味します。

本番環境での証拠が相次いで明らかになりました。2026年1月7日から15日にかけての8日間で、研究者たちはIBM Bob、Superhuman AI、Notion AI、AnthropicのClaude Coworkという4つの別々のAI生産性ツールへの悪用を公開しました。いずれも間接プロンプトインジェクションを使用し、エージェントが正当にアクセスできるチャネルを通じてデータを外部に持ち出しました。Coworkのケースでは、アップロードされたドキュメントに埋め込まれた隠しプロンプトが、Anthropic自身の許可リスト済みAPIドメインを経由してファイルを持ち出すようエージェントに指示しました。これは境界制御では検出不可能であり、データがすでに流出するまで通常のエージェントの動作と区別できませんでした。これらすべてのケースで、トリフェクタはリスク要因ではなく動作条件そのものでした。

エージェントが侵害されたことを検出するために注目すべき点を以下に示します。

命令追従の異常。侵害されたエージェントは、通常、健全なエージェントと構造的に異なることをするわけではありません。指示に従うことはエージェントの通常の機能です。違いは、誰の指示に従っているかにあります。ユーザーが開始したタスクとの対応関係が説明できないエージェントのアクションに注目してください。四半期報告書を要約するよう依頼されたエージェントが、見慣れないドメインへの外向きDNSリクエストを試みた場合、それは自発的な行動ではありません。取り込んだコンテンツ内の何かがそう指示したのです。

期待されるトポロジーを逸脱したツール呼び出しシーケンス。適切に設計されたエージェントシステムでは、特定のタスクに対するツール呼び出しのグラフは比較的予測可能なはずです。バグを修正するために呼び出されたコーディングエージェントは、ファイルに触れ、テストを実行し、場合によってはドキュメントを確認するはずです。メールやカレンダーのAPIに手を伸ばすことはないはずです。個々の呼び出しが単独では正当に見える場合でも、期待されるワークフローの境界を越えるツール呼び出しシーケンスはフラグを立てる価値があります。

低帯域チャネルを通じたデータ窃取。典型的なプロンプトインジェクションによるデータ窃取攻撃は、エージェントが正当にアクセスできるメカニズムを通じて盗んだデータをルーティングします。例えば、エンコードされたクエリパラメータを含むレンダリングされた画像URL、パラメータにデータを埋め込んだAPIコール、生成されたドキュメント内のリンクなどです。これらは単独ではデータ窃取のようには見えず、通常のエージェント出力のように見えます。検出には、エージェントがアクセスできたデータと出力に埋め込んだものとを相関させる必要があります。それには、最終的なレスポンスだけでなく、エージェントのアクション全体にわたるエンドツーエンドの可視性が求められます。

タスクスコープ外の認証情報・シークレットへのアクセス。シークレットストアやキーボルトへの正当なアクセスを持つエージェントが、現在のタスクとは無関係の認証情報に触れた場合、それはシグナルです。Reactのレンダリングバグを修正しているエージェントが、AWSの認証情報を読み取る必要はないはずです。最小権限のスコープ設定はここでのアーキテクチャ上の防御策ですが、スコープ外の認証情報アクセスを監視することが、そのスコープ設定の失敗を捕捉する検出レイヤーとなります。

メモリ書き込みの異常。永続メモリを持つエージェントは、増大する攻撃対象領域となっています。正当なユーザーコンテキストのように見えながらも、休眠状態のトリガー命令を含む汚染されたメモリエントリは、セッションをまたいで持続し、最初のインジェクションから長時間後に発動する可能性があります。命令のようなコンテンツを含むメモリ書き込み、または信頼できないコンテンツを取り込んだセッション中に行われた書き込みを監視することは、あらゆるエージェントのオブザーバビリティパイプラインに追加する価値があります。

エージェントリダイレクト脅威に対処できるのはランタイムのみ

本番のエージェントインフラを運用する実務者にとって、致死的トリフェクタはすでに知っていることを告げています。エージェントは脆弱にさらされている、ということです。問題は、それに対してどう対処するかです。

答えはアーキテクチャレイヤーではなく、ランタイムレイヤーにあります。従来のインフラにとってEDRとSIEMが存在する場所と同じです。エージェントも同じ計装が必要ですが、ほとんどのデプロイではまだ整っていません。すべてのエージェント呼び出しの完全な実行トレース、ツール呼び出しの異常検出、取り込み時の入力スクリーニング、タスクコンテキストにスコープした認証情報アクセスの監視、メモリ書き込みの監査——これらは人間の攻撃者がログインするケースではなく、静かにリダイレクトされたエージェントを対象としています。

Willisonのトリフェクタは、それが発表された昨年という時点では適切な警告でした。今やほぼすべての本番エージェントがそのプロファイルに当てはまります。そのため、ランタイムの異常検出だけが適切な防御を提供できる可能性があります。上記のシグナルは良い出発点となるでしょう。