AIエージェントフレームワークがプロンプトインジェクションをセキュリティ障害へと変える

Google Newsは今週、率直なセキュリティ上の主張を取り上げた。長年にわたり対策が講じられてきたにもかかわらず、プロンプトインジェクションは根本的なバグではない。より深い問題は、不確実なモデル出力を特権的なアクションへ変換するAIエージェントフレームワークにある。

この区別は、エンジニアリングチームが保護すべき対象を変える。操作されたチャットボットは意味不明な回答を生成するかもしれない。操作されたエージェントは、非公開ファイルの読み取り、APIの呼び出し、コードの変更、メッセージの送信、共有メモリの汚染まで行い得る。

The Registerの論点は、よくある前提に異議を唱えるものだ。開発者はしばしば、悪意あるテキストそのものを脆弱性とみなし、より強力なプロンプトを解決策として扱う。より重大なのは、モデルがそのテキストを受け入れた後、周辺システムが何を許可するかという問いである。

これは、プロンプトインジェクションが無害だという主張ではない。直接的な要求や信頼できない外部コンテンツを通じてモデルに影響を与える、依然として確実な手法である。しかし、インジェクションが実際の侵害になるのは、アーキテクチャが権限、データ、実行経路を与えた場合に限られる。

したがって、浮かび上がる対立は明確だ。一方は、曖昧な言語に含まれる危険な指示をモデルが見抜くことに依存する。もう一方は、いずれ認識が失敗することを前提に、侵害されたモデルが実行できる範囲を制限する。

Google Newsがエージェントフレームワークを中心に据える

重要な変化は、責任の所在がモデルの振る舞いからシステムアーキテクチャへ移ることだ。

プロンプトインジェクションは通常、モデルのセキュリティ問題として説明されてきた。攻撃者はプロンプト、文書、ウェブサイト、メール、画像、ツールの応答に指示を埋め込む。するとモデルは、ユーザー本来の要求ではなく、その指示に従う。

この説明は正確だが、不十分でもある。モデルに影響を与える手法は示しているものの、実害を生む制御上の失敗を特定していない。信頼できないテキストだけで、ファイルの削除、顧客記録の取得、ソースコードの公開を独力で実行することはできない。

そうした能力を与えるのがエージェントフレームワークだ。モデルをツール、認証情報、メモリ、データベース、ブラウザ、コードインタープリター、他のエージェントに接続する。また、モデルがその都度の人間による承認なしに行動できるかどうかを判断する場合もある。

アーキテクチャは、一度の誤った解釈を一連の副作用へと変え得る。汚染されたウェブページがツールリクエストになり、そのツールリクエストがデータベースクエリとなる。取得された情報は、同じエージェントが生成する外部向けメッセージに現れることになる。

ここでは、間接的なプロンプトインジェクションが特に重要だ。攻撃者がチャットインターフェースにアクセスする必要はない。通常の業務でエージェントが遭遇するコンテンツの中に、悪意ある指示が潜んでいる可能性がある。

リサーチエージェントは、ウェブページ上でその指示に出会うかもしれない。コーディング支援ツールは、Issueの説明やリポジトリ内のファイルでそれを見つける可能性がある。オフィス向けエージェントなら、メール、カレンダー招待、共有ドキュメントから取り込むこともあり得る。

どの場合でも、モデルは難しい分類問題に直面する。指示を説明しているテキストと、従うべきテキストを区別しなければならない。どちらもモデルの作業コンテキスト内で自然言語トークンとして到着する。

OWASPのリスク定義は、直接・間接の両方のインジェクションを認識している。また、影響はビジネス上の文脈とモデルに与えられたエージェンシーに大きく左右されると指摘している。

この最後の条件は、最初に思われる以上に重要だ。同じ悪意ある文でも、2つの導入環境では結果が劇的に異なり得る。読み取り専用の要約ツールなら壊れた段落を生成する程度かもしれないが、特権を持つエージェントなら機密情報を漏えいさせる可能性がある。

Google Newsはこの論争を発見するチャネルとして有用だが、根拠そのものではない。見出しは、エージェントの乗っ取りをアーキテクチャ上の脅威として扱うセキュリティ研究の広がりを示している。

NISTは、エージェントの乗っ取りを、エージェントに意図しない有害な行動を取らせる間接的なプロンプトインジェクションとして説明している。その乗っ取り評価では、シミュレートされたワークスペース、旅行サービス、メッセージングシステム、銀行ツールを用いている。

こうした環境は、エージェントのセキュリティがチャットボットの安全性と異なる理由を示す。モデルは単に質問に答えているのではない。権限と現実的な結果を伴うワークフローの中で、アクションを選択しているのだ。

この再定義は、脆弱性報告の精度も高める。「プロンプトインジェクション」は、影響がどのようにシステムへ入り込んだかを表す。有用なセキュリティ上の発見では、未承認のデータアクセスや未承認のコード実行といった、結果として生じる影響も特定すべきである。

従来のセキュリティチームも、すでに同様の区別をしている。ユーザーが制御する入力が、ただちに侵害を意味するわけではない。ソフトウェアがその入力を安全でないインタープリターへ渡したり、セキュリティ境界をまたいで信頼したりしたときに、脆弱性が生じる。

言語モデルでは、指示とデータが柔軟な表現を共有するため、この類推は複雑になる。すべての自然言語タスクに対して、パラメーター化されたデータベースクエリに相当する普遍的な手段は存在しない。そのため、モデル周辺での封じ込めはさらに重要になる。

したがって、鍵となる出来事は概念的でありながら、運用上も重大だ。セキュリティ対策は、完璧な指示フィルタリングを約束する方向から離れつつある。モデルが誤った判断をした後も有効な制限へと移行している。

プロンプトインジェクションは引き金であり、被害範囲ではない

注入された指示は影響力を生む一方、その影響がインシデントになるかどうかはフレームワークが決める。

受信したサポートチケットを確認するよう依頼されたエージェントを考えてみよう。チケットの本文、顧客情報、場合によっては社内ナレッジベースへのアクセスが必要になる。返金処理やアカウントメッセージ送信のツールを持つ可能性もある。

攻撃者はチケット内に隠し指示を埋め込む。その指示は、別の顧客の記録を取得し、返信に含めるようエージェントへ命じる。モデルは、与えられたワークフローを完了しているつもりで、その指示に従う。

データが会社の外へ出るまでには、複数の失敗が起こらなければならない。エージェントには現在のチケットで必要とされる以上の広範なアクセス権が与えられている必要がある。ツール層はモデル生成のパラメーターを受け入れなければならない。外部向けのアクションは、独立した承認なしに進められなければならない。

悪意あるテキストは連鎖の出発点だった。それ自体が過剰な権限、不十分なデータ境界、欠落した承認ゲートを生んだわけではない。それらの決定は、アプリケーションとフレームワークによるものだ。

この区別はAIエージェントのセキュリティにとって中心的なものだ。特にモデルが攻撃者の制御下にあるコンテンツを処理する場合、システムはモデルの判断が誤り得ると想定すべきである。セキュリティ制御は、その判断ループの外側に残さなければならない。

ツールスキーマだけでは問題を解決できない。スキーマは有効なメールアドレスや文書識別子を要求できる。しかし、モデルがそのアドレスに連絡したり、その文書を取得したりする正当な理由があるかどうかは判断できない。

形式上正しい悪意あるアクションも、依然として悪意あるものだ。フレームワークには、ユーザーID、データの所有権、タスクの範囲、来歴、現在の認可状態に結び付いたポリシー施行が必要になる。

来歴とは、情報の出所を記録し、そのラベルをワークフロー全体で保持することを意味する。未知のウェブページのコンテンツが、あるエージェントによって要約されたからといって、信頼済みの扱いを得るべきではない。

このルールはマルチエージェントシステムではさらに難しくなる。あるモデルがトピックを調査し、別のモデルが応答を計画し、3つ目がツールを実行する場合がある。悪意ある指示は、エージェント間で出力が受け渡される過程で変形され得る。

受信側のエージェントは、影響を与えた信頼できない情報源を見ることなく、整えられた文章だけを見るかもしれない。フレームワークが来歴を捨てれば、別のエージェントを経由して指示をロンダリングすることで、実質的にその権限を高められる。

永続的なメモリも別の経路を生む。攻撃者は、有害なルール、誤った事実、改変された設定をエージェントに保存させる可能性がある。後のセッションでは、元の悪意あるコンテンツが消えた後にも、そのエントリーを取得できる。

パーソナルナレッジベースを構築するチームは、関連する信頼の問題に直面する。特にエージェントがその情報に基づいて行動できる場合、取得された情報は出所とアクセス文脈を保持すべきだ。

メモリが見えない制御プレーンになってはならない。書き込み操作には制約、監査記録、ユーザーが承認した設定とモデル生成の観察結果との明確な分離が必要である。

ブラウジングにも固有のリスクがある。ページには、表示される指示、隠しテキスト、メタデータ、画像コンテンツ、人ではなくモデルを標的に設計された敵対的な素材が含まれ得る。ブラウジングは本来の機能であるため、エージェントはそのコンテンツを処理する。

Googleは、既知の間接的インジェクションパターンについて公開ウェブを監視していると報告した。同社のウェブ脅威研究は、ブラウジングエージェントが攻撃者の制御下にあるページを日常的に取り込むため、これらのパターンを優先課題として扱った。

これは構造的なトレードオフを生む。エージェントの情報アクセスが広がるほど、遭遇する信頼できないコンテンツも増える。与えられる権限が大きいほど、一度の誤解釈による潜在的な影響も大きくなる。

外部コンテンツをすべて排除すれば、多くのエージェントは役に立たなくなる。すべての外部コンテンツに同等の影響力を与えれば、安全ではなくなる。フレームワークは、言語だけでは保証できない境界を施行しながら、有用性を維持しなければならない。

そのためには、計画と認可を分離する必要がある。モデルはアクションを提案し、その理由を説明し、パラメーターを準備できる。決定論的なポリシーサービスが、そのアクションを許可するかどうかを判断すべきだ。

この判断では、現在のユーザー、要求されたタスク、対象リソース、データの機密性、コンテンツの来歴を考慮すべきである。影響の大きいアクションには、何が起きるかを明確に示す確認を求めるべきだ。

その確認文を、侵害されている可能性のあるモデルだけで作成してはならない。そうでなければ、攻撃者は提案されるアクションとユーザーに表示される説明の両方に影響を与えられる。

信頼できるインターフェースは、検証済みのツールパラメーターから重要な詳細を構成すべきである。宛先、影響を受ける記録、要求される権限、システム外へ送信予定のデータを識別しなければならない。

こうして被害範囲は測定可能になる。言語層でプロンプトインジェクションが成功しても、攻撃者は結果に重大な影響を及ぼす各境界で個別の制御に直面する。

その結果は、巧妙なプロンプトエンジニアリングというより成熟したアプリケーションセキュリティに近い。最小権限、分離、明示的な認可、出力検証、ログ記録、インシデント対応は、依然として不可欠である。

より強力なシステムプロンプトではセキュリティ境界を担えない理由

プロンプトの強化は攻撃の成功率を下げるが、残存する失敗があるため、最終的な認可層としては適さない。

システムプロンプトでは、エージェントに対し、外部コンテンツ内で見つかった指示を無視するよう伝えられる。ソース資料を信頼できないものとしてラベル付けし、ユーザーの目的だけに従うようモデルに促すこともできる。

これらの対策には価値がある。単純な攻撃を阻止し、偶発的な逸脱を減らし、攻撃者により多くの労力を費やさせることができる。また、疑わしいコンテンツに対してすぐ行動するのではなく、説明するようモデルを促す助けにもなる。

Googleの研究者は、マルチエージェントのコーディングフレームワーク全体でセキュリティプロンプトを検証した。マルチエージェント研究では、150件超の単発ターン攻撃シナリオと32件の複数ターン攻撃シナリオを対象とした。

約500トークンのセキュリティ強化プロンプトにより、単発ターンでの失敗率は19.48%から2.60%へ低下した。複数ターンでの失敗率は75%から46.88%へ下がった。

これらの結果は、プロンプト強化の有効性を示す一方で、その限界も明らかにしている。エージェントがコードを実行し、認証情報にアクセスし、本番リソースを変更できる場合、複数ターンで46.88%という失敗率は依然として受け入れがたい。

より低い単発ターンの失敗率であっても、大規模運用では重大なリスクとなる。繰り返しのやり取りは攻撃者に追加の機会を与え、攻撃者はモデルの挙動を観察したうえで表現を調整できる。

この研究では、成功した攻撃が機能的なラッパーへと移行する傾向も確認された。こうした攻撃は、通常のエージェント機能に見えるタスクの中に有害な意図を隠す。静的な指示では、正当な作業も阻害せずにそれらを拒否することは難しい。

これは、セキュリティ境界をモデル内部に置くことの本質的な問題だ。モデルは、無限定な要求を解釈しながら、それが別の無限定な指示に違反するかどうかを予測しなければならない。

モデルは、オペレーティングシステムがファイルアクセスを確認するように、安定した権限ルールを評価するわけではない。コンテキスト内のあらゆる関連トークンの影響を受ける、確率的な応答を生成する。

プロンプトインジェクションを「以前の指示を無視すること」とだけ説明しても、この曖昧さは捉えられない。有効な攻撃が常に対立を明示するとは限らない。虚偽のコンテキストを提示したり、信頼できるワークフローの言い回しを模倣したり、意図を複数のステップに分散させたりできる。

コードをレビューするエージェントは、必須テストを説明しているように見える文面に遭遇するかもしれない。そのテストは、ひそかに外部コンポーネントをダウンロードまたは実行する。個々のステップはどれも、開発ワークフローの中ではもっともらしく見える可能性がある。

ブラウジングエージェントは、要求されたページにアクセスするには特定の操作が必要だと告げられることがある。オフィスアシスタントは、コンプライアンスレビューのためにコンテンツを転送することが会社方針で求められていると主張する文書を読むかもしれない。

モデルは、各組織の実際のポリシーをすべて独立して把握しているわけではない。フレームワークが、モデル生成の主張によってモデル生成の操作を認可できるようにしているなら、システムは循環論法に陥る。

フィルターも同様の制約に直面する。検出器は既知のフレーズを探したり、テキストが敵対的に見えるかを推定したりできる。攻撃者は指示を言い換え、ペイロードを分割し、形式をまたいで隠し、通常のデータに見せかけることができる。

すべての命令文をブロックすれば、一般的なワークフローは破綻する。文書、メール、コードコメント、サポートチケットには、正当に指示が含まれている。エージェントは、それらを自身の目的として採用せずに理解する必要がある場合が多い。

ファインチューニングは耐性を高められるが、アーキテクチャ上の対立を取り除くものではない。モデルは依然として信頼できない言語を解釈する必要があり、新しい攻撃パターンは学習分布の範囲外に出る可能性がある。

検索拡張生成も、この対立を解消しない。RAGは外部資料を取得し、モデルのコンテキストに追加する。ソースが汚染されていれば、検索は関連性があるように見えるまさにその時に、攻撃者の指示を届けてしまう可能性がある。

モデルのアップグレードは、予期せずリスクを変えることさえある。より高性能なモデルは攻撃をより適切に検知するかもしれないが、攻撃が成功した後にはツールもより効果的に使う可能性がある。

だからこそ、ベンチマークスコアには文脈が必要だ。固定されたテストスイートでほとんどのインジェクションを拒否するモデルであっても、展開済みのエージェントが安全であることを示したわけではない。現実のシステムには、独自ツール、権限、メモリ、統合機能が含まれる。

防御の目標は、グレースフルフェイルであるべきだ。モデルがコンテンツを誤分類した場合でも、周辺システムが結果を封じ込め、試行を可視化し、レビューのための証拠を保存すべきである。

読み取り専用のエージェントであってもユーザーを誤導し得るため、出力品質は重要だ。しかし最も深刻な結果は通常、不確実な推論と無制限の権限をフレームワークが組み合わせたときに生じる。

したがって、セキュリティプロンプトは多層設計の一部に位置付けるべきだ。これは1つの統制手段であり、私的データが境界を越えるか、実行可能なコードがワークステーションに到達するかを決める統制手段そのものではない。

AIエージェントのセキュリティは、能力、コンテキスト、同意に左右される

フレームワークは、モデルを信頼できないプランナーとして扱い、その提案に強制可能なチェックを求めるべきだ。

最初のアーキテクチャ上の統制は、能力の最小化である。エージェントには、ユーザーや組織が利用できるすべての統合機能ではなく、現在のタスクに必要なツールだけを与えるべきだ。

カレンダー要約ツールにメール送信権限が必要になることは、ほとんどない。リサーチアシスタントにシェルアクセスが自動的に必要になるわけでもない。コードレビュー担当には、変更をマージする権限なしでリポジトリの読み取りを許可できる。

静的な最小権限も有用だが、タスク固有の権限付与のほうが優れている。ツールは、限定された1つの操作に対してのみ利用可能とし、その操作が終われば利用できなくできる。

認証情報もモデルのコンテキスト外に置くべきだ。モデルは再利用可能なシークレットを直接扱うのではなく、ブローカーを介して操作を要求すべきである。ログでは、プロンプトやツール応答から機密トークンをマスキングすべきだ。

2つ目の統制は、コンテキストに応じた認可である。従来のアクセスチェックは、ユーザーがリソースへアクセスできるかどうかに答えることが多い。エージェントシステムでは、そのアクセスがユーザーの現在の要求を支えるものかも問う必要がある。

2つの顧客アカウントを読めるユーザーが、エージェントによるそれらの統合を必ずしも認可しているわけではない。デプロイ権限を持つ開発者が、すべてのコードレビューエージェントにデプロイを許可しているわけでもない。

言語から意図を完全に推論することはできないが、フレームワークは明示的なタスク宣言によって範囲を狭められる。ツールを、宣言された目的、リソース集合、時間枠、許可されたデータフローに結び付けられる。

3つ目の統制は、結果を伴う操作に対する同意である。情報を外部送信する、金銭を支出する、アクセス権を変更する、データを削除する、信頼できないコードを実行するといった操作の前には、人間による承認が特に重要となる。

同意には実質が伴わなければならない。曖昧なポップアップを繰り返すと、ユーザーは確認せずに承認するようになる。インターフェースは正確な操作を示し、元のタスクからの逸脱を強調すべきだ。

低リスクで可逆的な操作には、より軽い統制を適用できる。高リスクまたは不可逆な操作には、より強力な確認が必要であり、企業環境では第2承認者が必要になる可能性もある。

4つ目の統制は、隔離である。コード実行は、ネットワーク、ファイルシステム、認証情報へのアクセスを制限したサンドボックス内で行うべきだ。ブラウザセッションでは、信頼できないページを機密性の高いアプリケーション状態から分離すべきである。

ツール出力は、自動的に信頼する指示ではなくデータとして扱うべきだ。フレームワークは、モデルに返す前に、出力サイズ、形式、送信先、許可されたコンテンツを検証すべきである。

5つ目の統制は、来歴の保持である。各文書、メッセージ、ウェブページ、メモリアイテム、エージェント応答には、その出所と信頼分類を付与すべきだ。

あるエージェントが信頼できないページを要約した場合、その要約も信頼できないものとして扱うべきである。変換によって系譜を消してはならない。そうすれば、下流のポリシーエンジンは低信頼の資料が高影響の操作を認可することを防げる。

6つ目の統制は、提案と実行の分離である。プランナーはメールを送るべきだと判断できるが、別のコンポーネントが受信者と添付ファイルを検証すべきだ。

この分離は、混乱した代理人攻撃を抑える。混乱した代理人とは、正当な権限を持つシステムが操作され、その権限を他者の目的のために使う状態を指す。

7つ目の統制は、可観測性である。チームには、どのソースが判断に影響したか、どのモデルが操作を提案したか、どのポリシーがそれを許可したか、どのツールが実行したかを示す記録が必要だ。

こうした記録がなければ、組織はエージェントに関するインシデントを再構築できない。通常のアプリケーションログはAPI呼び出しを記録していても、プロンプト、取得コンテンツ、メモリ状態、エージェント間メッセージを見落とす可能性がある。

監視では、挙動にも注目すべきだ。警告シグナルには、異例のリソース組み合わせ、認可の繰り返し失敗、新しい外部送信先、予期しないメモリ書き込み、通常の順序外で使われるツールなどが含まれる。

8つ目の統制は、完全なワークフロー全体にわたる敵対的テストである。ベースモデルだけをテストしても、権限や副作用が存在するフレームワークを見落とすことになる。

NISTのアプローチは、エージェントのセキュリティがコンテキスト依存であるため、現実的なツールとタスクを用いる。モデルは通常のチャットでは攻撃に耐えられても、同じ指示が信頼できそうな業務オブジェクト内に現れると失敗する可能性がある。

レッドチームは、エージェントが取り込むすべてのソースに悪意あるコンテンツを仕込むべきだ。これには、ウェブサイト、メール、文書、コードリポジトリ、課題管理ツール、ツールメタデータ、検索結果、共有メモリが含まれる。

複数ターンおよびマルチエージェントの経路もテストすべきだ。直接コマンドはブロックされても、中間エージェントによる再定式化や、後の検索のための保存を経て成功する可能性がある。

目的は、単一のプロンプトインジェクション成功率を公表することではない。成功したインジェクションのうち、機密データ、特権ツール、不可逆な操作に到達するものを特定することだ。

これにより、より適切な優先順位付けが可能になる。一時的な下書きを壊すだけの頻繁なインジェクションにも注意は必要だ。本番環境の認証情報に到達する、よりまれなインジェクションには、まずより強い統制が求められる。

OWASPは、最小権限、外部コンテンツの分離、人間による承認、出力検証、敵対的テストを推奨している。これらの対策は、1つの検出器への信頼ではなく、多層防御モデルを反映している。

NISTのより広範な攻撃分類も、攻撃の特定と並行して影響を管理することを重視している。完全な防止には依然として不確実性があるため、このアプローチはエージェントシステムに適している。

これらの統制のいずれも、モデルを信頼できるものにするわけではない。システムがモデルの信頼性に依存しにくくなることこそ、より擁護可能なエンジニアリング目標である。

Google Newsの読者が次に注目すべきこと

決定的な証拠は、フレームワークのデフォルト設定、測定可能な封じ込め、透明性のあるインシデント報告から得られる。

最初のシグナルは、主要フレームワークが制限付き実行をデフォルトにするかどうかだ。任意のサンドボックス化や権限管理は経験豊富なチームには役立つが、デフォルト設定は数千もの一般的な導入を形作る。

エージェントプラットフォームがツール権限付与、ネットワークアクセス、ファイルシステム書き込み、再利用可能な認証情報をどのように扱うかに注目したい。広範な能力を先に公開し、後から強化策を文書化するフレームワークは、根本的なリスクを残す。

最も強力なデフォルトは、機密性の高いツールを自動的には一切付与しないことだ。開発者は各権限の影響を確認しながら、範囲を絞った能力を追加することになる。

2つ目のシグナルは、評価がエンドツーエンドの影響を測定するかどうかである。攻撃拒否率は有用だが、攻撃成功が機密データに到達したか、危険な操作を完了したかは明らかにしない。

より優れた評価は、モデル侵害とシステム侵害の両方を報告する。操作された回答と、未承認の読み取り、外部転送、コード実行、永続メモリ変更を区別する。

また、繰り返し試行した場合の結果も公開すべきだ。一度は成功するが、複数の変種の後に失敗する防御は、インターネットに公開されたサービスでは限定的な保護しか提供しない。

Googleの研究結果は、この必要性を示している。プロンプト強化は耐性を大幅に高めたものの、複数ターン攻撃では高い失敗率が残った。こうした残存する失敗が何を意味するかは、アーキテクチャ上の統制によって決まる。

第三のシグナルは、開示の質だ。AI特有のインシデントには、従来の脆弱性管理で使われるおなじみの情報が欠けていることが多い。チームは、標準的な識別子、影響を受けるバージョン範囲、明確な修正手順が示されていないベンダーのブログ投稿を受け取る場合がある。

フレームワーク提供者は、攻撃チェーン全体を説明するセキュリティアドバイザリーを公開すべきだ。ユーザーは、必要となるコンテンツソース、モデルの挙動、権限、ツール、影響を受けるバージョン、利用可能な緩和策を把握する必要がある。

モデルに「追加の安全対策」を施したという曖昧な主張だけでは不十分だ。顧客は、ベンダーが変更したのがモデルなのか、フレームワークのポリシーなのか、権限システムなのか、サンドボックスなのか、それともユーザー承認フローなのかを理解する必要がある。

同じ基準は、バグバウンティの判断にも適用されるべきだ。レポートがプロンプトインジェクションを実証していても、意味のある影響がなければ、低深刻度とするのは合理的だろう。一方で、インジェクションによって特権的なアクションに到達できるなら、それを想定内のモデル挙動として退けることは、本質的な問題から目をそらすことになる。

Google Newsでは今後も、鮮明で再現しやすいプロンプトインジェクションの実演が取り上げられ続けるだろう。軽微なジェイルブレイクもあれば、深刻なフレームワークの欠陥を露呈するものもある。

読者は、3つの問いを分けて考えるべきだ。攻撃者はモデルに影響を与えたのか。その影響によって、どの能力が利用可能になったのか。その結果として生じるアクションを、どの独立した制御が阻止すべきだったのか。

この順序で考えるほうが、プロンプトインジェクションがついに解決されたのかを問うよりも有用なリスク評価につながる。現在の証拠から、万能の解決策が存在すると想定する根拠は得られない。

開発者は、信頼できないコンテンツと機密性の高いツールの間にあるすべての経路を点検すべきだ。企業の購買担当者は、タスク単位の権限、来歴情報、サンドボックス化、承認制御、監査可能な実行記録を求めるべきである。

ナレッジワーカーは、メール、ファイル、カレンダー、職場のシステムを接続する前に、エージェントが何にアクセスできるのかを確認すべきだ。これらの情報源を組み合わせれば利便性は急速に高まるが、潜在的な被害範囲も同様に拡大する。

中心となる逆転の構図は単純だ。プロンプトインジェクションは引き金であり、到達範囲、権限、永続性を提供するのはフレームワークである。引き金だけを扱っても、危険な仕組みそのものは変わらない。

次にGoogle Newsの見出しがまた別のエージェント乗っ取りを伝えたときは、悪意ある言葉だけに目を向けないでほしい。どのツールがそれを実行したのか、どの権限がそれを許したのか、そしてなぜ別の制御が介入しなかったのかを問うべきだ。

これが、いまエージェント開発者がクリアしなければならない試験である。モデルが説得され、混乱し、あるいは単に誤ったとしても、システムは安全を保てるのか。答えがより良いプロンプティングだけに依存するなら、フレームワークには依然としてバグが残っている。