Safe Url は、OpenAI が プロンプトインジェクションに耐える AI エージェントの設計 で説明している緩和策であり、アシスタントがすでに攻撃者に説得されてしまったケースを対象としている。これは、アシスタントが会話の中で知った情報が第三者に送信されようとしていることを検知するよう設計されている。検知すると、システムは送信されようとしている情報をユーザーに示して確認を求めるか、送信をブロックして、ユーザーのリクエストを前に進める別の方法を試すようエージェントに伝える。

防御の中での位置づけは、意図的に最後に置かれている。記事によれば、同社のアシスタントに対して最もよく見られる攻撃は、会話から秘密の情報を取り出して悪意ある第三者に送るよう説得しようとするものであり、既知のケースの大半では、安全性の訓練によってエージェントが拒否するため、そうした攻撃は失敗する。Safe Url は、主要な防壁としてではなく、まれに残るケース――エージェントが説得されてしまったケース――に対処するものとして提示されている。

用法

この仕組みは、同じ記事で示されている ソース・シンク分析 の枠組みから導かれる。攻撃者にはソースとシンクの両方が必要であり、エージェント型システムでは、シンクは多くの場合、第三者に情報を送信する、リンクをたどる、ツールとやり取りするといったアクションである。Safe Url はそのシンクに作用するものであり、それが守ろうとするセキュリティ上の期待は、潜在的に危険なアクションや機微な情報の送信が、黙って、あるいは適切な安全策なしに行われるべきではないということである。

同じ仕組みはチャットを超えて適用されていると報告されている。ベンダーのブラウザ製品におけるナビゲーションとブックマーク、そしてディープリサーチ製品における検索とナビゲーションである。同社の canvas 機能と apps 機能も同様のアプローチを採っていると説明されており、予期しない通信を検知してユーザーに同意を求めることができるサンドボックスの中で動作する。

適用される場面

この緩和策は、エージェントが会話からの情報を保持し、それを外部へ移しうる何らかの能力を持っている場面に適用される。それは、そうした送信を発生前に認識できること、そしてシステムがブロックではなく確認を選んだときに、確認するユーザーがその場にいることを前提としている。したがって、確認する場合には ヒューマン・イン・ザ・ループ の統制であり、無人のエージェントについてはそれに伴う限界がある。これはデータ持ち出しに特化したものであり、損害が何か別の重大なアクションを通じて生じるような操作を対象とするものではない。

確立の度合い:これは 1 つのベンダーが自社で展開している防御について、自社のサイトで公開した説明である。記事は、この仕組みの構造に関する論文が別の専用記事に存在すると述べているが、ここでは有効性の数値を示しておらず、この情報源には独立した評価も含まれていない。

関連用語