Skip to main content
AIエージェントの情報漏洩リスクを説明するとき最もよく引用されるのがSimon WillisonのThe Lethal Trifectaです。そしてこの脅威への現実的な対策としてMetaが示したのがAgents Rule of Twoです。前者が指摘するリスクと後者が示す対策を整理し、実際のエージェント基盤で運用するための視点を加えます。

​
The Lethal Trifecta

AIエージェントが次の3つの能力を同時に持つとき、攻撃者はエージェントを騙してプライベートデータを盗み出せます。
  • プライベートデータへのアクセス
  • 信頼できないコンテンツの読み込み
  • 外部への通信手段
原因はLLMの性質そのものにあります。LLMはコンテキストに入った指示に従いますが、その指示が操作者からのものか読み込んだWebページやメールに仕込まれたものかを確実に区別できません。すべては最終的に1つのトークン列としてモデルに渡されます。プロンプトに禁止を書き足しても、非決定的なシステムである以上毎回従う保証はありません。 この攻撃は仮説ではなく、Microsoft 365 CopilotやGitHub公式MCPサーバーなど本番システムで繰り返し報告されてきました。ベンダーは流出経路を塞ぐことで修正してきましたが、MCPの普及によりユーザーが自分でツールを組み合わせる時代になると、その組み合わせが3条件を満たすかどうかは利用者自身の責任になります。3つが揃う構成を避けること以外に確実な防御はないというのが元記事の結論です。

​
Agents Rule of Two

Metaはこの整理を実装可能な原則へ変換しました。プロンプトインジェクションを確実に検知・拒否できるようになるまで、エージェントは1セッション内で次の3性質のうち2つまでしか同時に満たしてはならないというものです。
  1. 信頼できない入力を処理する
  2. 機密システムやプライベートデータにアクセスする
  3. 状態を変更する、または外部と通信する
3つすべてが必要なタスクであれば自律動作を許可せず、human-in-the-loopによる承認など信頼できる検証を挟みます。守るべきは、1つ目で注入された命令が2つ目のデータへ到達し3つ目を通じて持ち出されるという攻撃連鎖の切断です。それが保たれるならセッション途中で構成を一方向に切り替えることもできます。たとえば外部通信を無効化してから内部システムへアクセスする構成です。ただしRule of Twoの充足は最小権限など既存原則の代替ではなく補完であり、これを満たしても過剰な権限やエージェントの誤動作といった他のリスクは残ります。

​
運用への3つの視点

2つの原則はシンプルですが、実際のエージェント基盤に落とすと考えることが増えます。運用にあたって重視すべき点を3つ挙げます。

​
決定論的な層で強制する

Prompt Injectionを完璧に防ぐことは不可能という前提に立つべきです。だからこそRule of Twoの価値は、モデルの判断に依存しない決定論的なルールである点にあります。ただしツール一覧を眺めて2つまでと数えるだけでは守れません。エージェントはcurlのようなコマンドで許可されていない通信を試みることができるため、3つ目の制限はネットワーク層の許可リストとして実装する必要があります。また認証情報付与プロキシを使えばエージェント自身に認証情報を一切持たせずに済み、命令が汚染されても流出するものがなくなります。ルールはエージェントが回避できない実行基盤の層で強制して初めて機能します。 あわせて攻撃側の変化も踏まえるべきです。プロンプトフィルタリング製品の発達により、検知されやすい直接的な命令上書きではなく正規の命令の形をした誘導へと攻撃は移っています。この変化は業界標準にも反映されました。OWASP LLM Top 10で筆頭に挙げられていたPrompt Injectionは、エージェントを前提としたOWASP Top 10 for Agentic Applications 2026ではAgent Goal Hijackという名前に変わり、単発の不正な入力ではなくエージェントの目標や計画そのものを乗っ取る攻撃として再定義されています。目標を乗っ取られたエージェントは自分ではユーザーの目的を追っていると信じたまま、攻撃者の目的に向かって多段の行動を自律的に実行します。1つ目の入力を検査して無害化する構成に頼るほど、この変化の影響を受けます。検査で守るのではなく構成で守るというRule of Twoの発想は、この点でも理にかなっています。

​
検証をhuman-in-the-loopだけに頼らない

3つすべてが必要な場合の検証手段としてまず挙がるのがhuman-in-the-loopです。しかし頻繁すぎる承認は承認疲れを起こし、ユーザーは判断せずYESを押すだけになります。これでは形だけの検証です。安全が担保されている挙動には自律動作を許容し、外部送信や削除のような不可逆な行動に承認を絞る設計が前提になります。 そして検証手段は人間の承認だけではありません。AIブラウザのようなハイリスクな領域では、本体とは別に切り離された小さなエージェントを動かし、提案されたアクションの正当性を実行前に検証するガーディアン・エージェントの構成が標準になりつつあります。Gemini in ChromeのUser Alignment Criticはその実例で、計画されたアクションがユーザーの当初の目的に資するかを別モデルが判定し、逸脱していれば拒否して再計画させます。要点はこの検証エージェントを信頼できないコンテンツから隔離することです。判定にはアクションのメタデータとユーザーの当初の指示という信頼できる入力のみを渡し、Webから取得した生のコンテンツは見せません。検証役まで同じ経路で汚染されれば多層防御そのものが崩れるためです。ただし検証エージェント自体も攻撃対象になり得るため、その許可を単独の根拠にはせず決定論的なポリシーとの組み合わせで最終判断し、応答がなければ実行を止めるfail-closedを徹底します。

​
権限の帰属まで含めて2つ目を設計する

Rule of Twoが扱うのは1セッション内の能力の組み合わせであり、その権限が誰に帰属するかは扱いません。共有のMachine Userで構成されたエージェントは、1つ目と3つ目を完全に塞いでも正当なユーザーの正当な質問だけで機密情報を漏らします。これはConfused Deputy Problemの領域です。逆に権限が要求者に正しく紐づいていれば、Prompt Injectionが成立してもエージェントは要求者の権限の範囲外へ踏み出せません。さらにエージェントの出力が誰に見えるかも実質的なアクセス権限を決定します。2つ目の範囲は、要求者への権限委譲と出力先の閲覧権限まで含めて初めて定まります。

​
参考文献