プロンプトインジェクションに耐性のある AI エージェントの設計

AI エージェントは、ウェブを閲覧し、情報を取得し、ユーザーの代わりに行動できるようになってきています。これらの機能は有用ですが、攻撃者がシステムを操作しようとする新たな手段も生み出します。

これらの攻撃は、多くの場合プロンプトインジェクション⁠と呼ばれます。これは、外部コンテンツ内に指示を仕込み、ユーザーが求めていないことをモデルに実行させようとする手法です。私たちの経験では、現実の攻撃の中で特に効果的なものは、単純なプロンプトの上書きというよりも、ソーシャルエンジニアリングに近いものになっています。

その変化は重要です。問題は、単に悪意ある文字列を特定することではありません。文脈の中で誤解を招いたり操作しようとしたりするコンテンツに抵抗することです。そのため、防御を入力のフィルタリングだけに頼ることはできません。また、一部の攻撃が成功した場合でも、その影響を抑えられるようにシステムを設計することも必要です。

初期の「プロンプトインジェクション」型の攻撃は、Wikipedia の記事を編集し、そこを訪れる AI エージェントに直接指示を書き込むだけで成立するような単純なケースもありました。こうした敵対的な環境を学習時に経験していない場合、AI モデルはそれらの指示に疑いなく従ってしまうことが多くありました¹。モデルがより賢くなるにつれて、この種の誘導に対する脆弱性も低下してきました。そして、プロンプトインジェクション型の攻撃はそれに対応する形で、ソーシャルエンジニアリングの要素を取り入れるようになってきたことが観察されています。

AI セキュリティの広い分野では、AI エージェントと外部との間に仲介層を置き、入力を「悪意あるプロンプトインジェクション」と「通常の入力」に分類しようとする「AI ファイアウォール」などの手法が推奨されることが一般的になっています。しかし、このような仕組みでは、十分に作り込まれた攻撃は通常検知できません。このような仕組みでは、悪意ある入力を見抜くことは、嘘や誤情報を見抜くのと同じくらい難しい問題になります。しかも多くの場合、必要な文脈がないまま判断しなければなりません。

実際のプロンプトインジェクション攻撃が複雑化するにつれて、最も効果的な攻撃手法はソーシャルエンジニアリングの戦術を利用していることが分かってきました。ソーシャルエンジニアリングを伴うプロンプトインジェクション攻撃を、まったく新しい種類の問題として扱うのではなく、他の分野で人間に対するソーシャルエンジニアリングのリスクを管理するのと同じ考え方で捉えるようになりました。こうしたシステムの目的は、悪意ある入力を完全に特定することだけではありません。たとえ操作が成功したとしても、その影響が限定されるようにエージェントやシステムを設計することにあります。このような設計は、プロンプトインジェクションとソーシャルエンジニアリングの両方の影響を抑えるうえで有効であることが示されています。

この観点から見ると、AI エージェントはカスタマーサービスの担当者と同様、三者が関わる環境の中で行動していると考えることができます。エージェントは雇用主の代理として行動する一方で、誤誘導を試みる可能性のある外部からの入力に常にさらされています。人間であれ AI であれ、カスタマーサポートのエージェントには、このような悪意のある環境に伴うリスクを抑えるため、行える操作に一定の制限を設ける必要があります。

人間がカスタマーサポートシステムを運用し、配送の遅延や故障による損害など、顧客が被った不便に対してギフトカードや返金を提供できる状況を想像してみてください。これは複数の当事者が関わる問題です。企業はエージェントが正当な理由に基づいて返金を行うことを信頼しなければならない一方で、エージェントは誤誘導を試みたり、場合によっては圧力をかけたりする第三者ともやり取りします。

現実では、エージェントには従うべきルールが与えられます。しかし、彼らが置かれている敵対的な環境では、誤誘導される可能性があることも前提とされています。たとえば、顧客が「返金が処理されていない」と主張するメッセージを送ってきたり、返金しなければ危害を加えると脅したりすることがあります。エージェントが利用する決定論的なシステムでは、顧客に提供できる返金額を制限したり、フィッシングの可能性があるメールを検知したりするなど、個々のエージェントが侵害された場合でも影響を抑えるための仕組みが設けられています。

この考え方に基づき、当社はユーザーが期待するセキュリティを守るための堅牢な対策を講じてきました。

ChatGPT では、このソーシャルエンジニアリングのモデルを、ソース／シンク分析などの従来のセキュリティエンジニアリング手法と組み合わせています。

この考え方では、攻撃者はシステムに影響を与える手段である「ソース」と、誤った文脈では危険になり得る機能である「シンク」の両方を必要とします。エージェント型システムでは、多くの場合、信頼できない外部コンテンツが、第三者への情報送信、リンクの追跡、ツールとのやり取りといったアクションと組み合わさる形で攻撃が行われます。

私たちの目標は、ユーザーが当然期待する基本的なセキュリティを守ることです。潜在的に危険なアクションや、機密性の高い可能性のある情報の送信は、ユーザーに気づかれない形で行われたり、適切な保護措置なしに行われたりしてはなりません。

ChatGPT に対して見られる攻撃の多くは、会話から秘密情報を取り出し、それを悪意のある第三者に送信すべきだとアシスタントに思い込ませようとするものです。私たちが把握しているほとんどのケースでは、安全性に関する学習によってエージェントが拒否するため、こうした攻撃は成功していません。それでもエージェントが説得されてしまう場合に備えて、私たちは Safe Url という緩和策を開発しています。これは、アシスタントが会話から得た情報が第三者に送信されようとしている場合を検知する仕組みです。このようなまれなケースでは、送信されようとしている情報をユーザーに表示して確認を求めるか、送信をブロックし、ユーザーのリクエストを進める別の方法を試すようエージェントに指示します。

同じ仕組みは、Atlas⁠ のナビゲーションやブックマーク、また Deep Research⁠ の検索やナビゲーションにも適用されています。ChatGPT Canvas⁠ と ChatGPT Apps⁠ でも同様のアプローチが採られており、エージェントが機能的なアプリケーションを作成して利用できます。これらは、想定されていない通信を検出し、ユーザーに同意を求める⁠（新しいウィンドウで開く）ことができるサンドボックス内で実行されます。

Safe Url の詳細やその仕組みに関する論文については、ブログ記事「Keeping your data safe when an AI agent clicks a link⁠」で紹介しています。

完全自律型エージェントには、敵対的な外部環境の中でも安全に動作できる設計が不可欠です。AI モデルをアプリケーションシステムと統合する際には、同じ状況で人間のエージェントならどのような制御が必要かを考え、それを実装することを推奨します。非常に高度な知能を持つ AI モデルであれば、人間のエージェントよりもソーシャルエンジニアリングにうまく抵抗できる可能性があります。しかし、アプリケーションによっては、それが常に実現可能とは限らず、コスト面でも適さない場合があります。

私たちは、AI モデルに対するソーシャルエンジニアリングの影響とその防御について引き続き研究を進め、その知見をアプリケーションのセキュリティ設計と AI モデルの学習の両方に取り入れていきます。