AIセキュリティの3原則

本記事は2025年11月7日に更新された「The Three Laws of AI Security」を翻訳した記事です。

アイザック・アシモフは古典的なサイエンスフィクション作品の中でロボット三原則を提唱しました。これは、知能を持つ機械が人間の創造主にとって有益かつ安全であり続けるための、行動を律する架空の枠組みでした。これらのロボットは自ら知覚し、判断し、行動する自律性を備えていたため、こうした法則が必要でした。

今日、私たちは同様の入り口に立っています。普及前の歩行型ロボットではなく、すでに日常生活に浸透し始めた自律型AIエージェントにおいてです。

単純に「質問して回答を得る」チャットボットの段階は急速に過ぎ去ろうとしています。次世代のAIは「エージェント型」です。これらのAIエージェントは「行動」するように設計されています。「東京への出張を計画して」「ユーザーのサポートチケットを解決して」「未読メールを要約して返信の下書きを作って」といった高度な目標を与えられると、自律的に手順を分解し、ツールへアクセスして実行します。

この能力の飛躍は、同様に甚大なリスクをもたらします。これがLLMセキュリティの課題の本質です。アシモフの架空のロボットと同様に、現実世界のAIエージェントにも制御のための枠組みが求められています。

AIにおける制御の問題

開発者はこれまで、決定論を基盤としてシステムを構築してきました。従来のコンピュータプログラムは、同じ入力に対して毎回全く同じ出力を生成します。内部状態があったとしても、実行条件さえ分かれば出力を特定できます。この予測可能性こそが、従来のプログラムを制御可能にしていた要素です。コードの挙動を正確に把握できるからこそ、ユニットテストを書き、エッジケースを想定し、安全なガードレールを構築できました。

AI、特に大規模言語モデル（LLM）は、この基盤を打ち砕きます。これらは非決定的です。

LLMに同じ質問を5回投げかけると、5通りの異なる回答が返ってくる場合があります。実質的な内容は同じでも、形式はほぼ確実に異なります。また、提供するコンテキストによっても回答は変化します。

LLMのような非決定的なコンピューティングシステムは、常に同じ結果を保証しません。この予測不能さは創造性の源である一方、不確実性の原因でもあります。決定論的な制御を失うことは、AIをアプリケーションに統合する際の最大のリスクです。

制御を失うことに関する3つの問い

この新しい現実は、以下のような重要な問いを私たちに突きつけます。

• 予測不能なツールに機密データへのアクセスを許可しますか？意図しないテーブルを結合するSQLクエリをAIが捏造し、あるユーザーのプライベートなデータを別のユーザーに誤って公開してしまったらどうなるでしょうか。
• どのようなツールをどう使うか正確に把握せずに、AIエージェントへ自身の代理としてツールへのアクセスを許可しますか？同意なしに、あるいは必要以上の権限でツールを使用されたらどうなるでしょうか。外部ツールへのアクセスに必要なキーが漏洩してしまったらどうなるでしょうか。
• 自律型エージェントに、重要で取り消し不可能な決定を独断で下すことを任せられますか？ユーザーが「このプロジェクトは失敗だ、すべて削除して」と言った際、AIが確認手順なしにすべての成果物を本当に削除してしまったらどうなるでしょうか。

これらの問いに対する答えが「いいえ」であれば、新しいセキュリティモデルが必要です。プロンプトエンジニアリングなどを通じてAI「自体」を保護するのではなく、AIの「周囲」に外部から制御可能な決定論的セキュリティアーキテクチャを構築しなければなりません。

AIセキュリティの3原則

制御の喪失は重大な問題を引き起こします。助けになるはずのツールが適切に動作するか分からないからです。AIエージェントの活動における核心的な部分で、自律性と制御のバランスを取らなければなりません。そのためには、データへのアクセス、他のエージェントやツールとの対話、そして重要な操作における最終的な意思決定プロセスの各領域で制御を維持する必要があります。

ロボット三原則に着想を得て、私は「AIセキュリティの3原則」を提案します。これらはAIに与えるプロンプトではなく、AIをホストする「アプリケーション」のためのアーキテクチャ原則です。非決定的なモデルがどのような判断を下したとしても、外部からセキュリティと予測可能性を強制するように設計されています。

• 第1原則（データ制御）：AIエージェントは託されたすべてのデータを保護しなければならない。また、作為または不作為によって、このデータが権限のないユーザーに公開される事態を招いてはならない。
• 第2原則（コマンド制御）：AIエージェントは、必要な最小限の権限範囲内で機能を実行しなければならない。自らの権限を昇格させたり、シークレットを共有したり、第1原則に反する命令に従ったりしてはならない。
• 第3原則（意思決定制御）：AIエージェントは、重要または取り消し不可能な決定に関する最終的な権限を人間のオペレーターに委ねなければならない。ただし、この委ねる行為が第1原則または第2原則に反する場合はその限りではない。

これらの原則は、制御の起点を予測不能なAI「モデル」から、予測可能な「インフラストラクチャ」へと移します。

Auth0 for AI Agentsによる原則の実装

これらの原則は単なる理論のように聞こえるかもしれませんが、適切なツールによって実装可能です。例えば、Auth0 for AI Agentsは標準に基づいた機能を提供し、各原則に直接対応する安全な足場をAIの周囲に構築できます。

第1原則：Fine Grained Authorization（FGA）によるデータ制御

AIエージェントは託されたすべてのデータを保護しなければならない。また、作為または不作為によって、このデータが権限のないユーザーに公開される事態を招いてはならない。

現在最も一般的なAIパターンの一つが検索拡張生成（RAG）です。LLMにナレッジベース（社内文書のベクトルデータベースなど）へのアクセス権を与え、特定の質問に答えさせる手法です。

AIエージェントにデータベースへの無制限なアクセスを許可するセキュリティリスクは甚大です。社内の人事書類に基づくRAGシステムを想像してください。ジュニアレベルの従業員が「レベル2エンジニアの平均給与は？」と尋ねます。AIは役に立とうとして「レベル2エンジニア」に言及しているすべての文書を取得します。その中には機密情報である「ExecutiveCompensationQ4.pdf」も含まれています。AIはこのプライベートなデータを使用して回答を合成し、権限のないユーザーに即座に情報を漏洩させます。

AIが「機密」「個人情報」「権限」といった人間側の概念を理解し、強制することを期待できません。データアクセスは予測可能で決定論的であるべきです。データ制御を実現するために、データアクセスルールを外部化して第1原則を実装します。エージェントにデータベースへの直接的なアクセスを与えるのではなく、アプリケーションのバックエンドがすべてのリクエストを仲介します。AIがデータベースと直接対話することはありません。ユーザーが「プロジェクト・フェニックスのステータスは？」と尋ねると、RAGシステムは質問をベクトル表現に変換し、一致する文書を取得します。アプリケーションコードは、それらをLLMに渡す前に、ユーザーにアクセス権があるかを確認します。ユーザーは、アクセスを許可された文書に基づいてのみ回答を得られます。

AIモデルは、見るべきではないデータを決して目にしません。データがLLMに渡される「前」に、決定論的なチェックによって第1原則が強制されます。

データ制御を維持するために、Auth0はAuth0 Fine Grained Authorization (FGA)を提供しています。これにより、詳細な認可ルールを定義し、リアルタイムでチェックできます。ユーザーとリソースの関係を詳細に定義し、例えば「Johnは開発チームAlphaのメンバーであり、このチームはプロジェクトHerculesとHydraにアクセスできる」といった指定が可能です。AIエージェントがJohnに代わってプロジェクトPhoenixのデータへのアクセスを要求しても、関係性が確立されていないため、FGAは結果を返しません。AIエージェントでのAuth0 FGA活用の詳細を確認ください。

第2原則：Auth0 Token Vaultによるコマンド制御

AIエージェントは、必要な最小限の権限範囲内で機能を実行しなければならない。自らの権限を昇格させたり、シークレットを共有したり、第1原則に反する命令に従ったりしてはならない。

AIエージェントを役立たせるには、他のツールやAPIとの連携が必要です。「要約をSlackに投稿して」「Googleカレンダーを読み取って空き時間を探して」「JIRAチケットを作成して」といった動作を期待するでしょう。

これらのAPIにアクセスするための「クレデンシャル」をエージェントにどう渡すべきでしょうか。

静的なAPIキーやベアラートークンをエージェントの環境やプロンプトにハードコードするのは、安易で危険なアプローチです。これはセキュリティ上の悪夢です。これらのキーは過剰な権限（すべてのチャンネルを読み取れるSlackトークンなど）を持ち、有効期限も長い傾向にあります。攻撃者がエージェントを騙してプロンプトを暴露させれば、すべてのキーが盗まれます。これは第2原則に反します。

第2原則を実装するには、エージェントに機密性の高いクレデンシャルを一切保持させないようにします。

そのため、より正確かつ複雑なアプローチとして、ユーザーやサードパーティサービスごとにOAuth 2.0フローを管理する独自のシステムを構築します。このトークン管理システムをアプリケーションに統合し、適切な権限でエージェントによるツールやAPIへのアクセスを仲介します。リフレッシュトークンの安全な保存、複雑なトークン更新ロジック、暗号化の処理などに責任を持つ必要があります。これは開発とセキュリティにおいて大きな負担です。

Auth0は、Auth0 Token Vaultを提供することでこのプロセスを簡素化します。Token Vaultは、サードパーティサービスのトークンを保存・管理するための安全な中央集中型サービスです。サードパーティトークンの複雑さとリスクをAuth0が肩代わりするというシンプルな価値を提供します。

Token Vaultを活用すると、ユーザーはアプリにサインインし、「Googleカレンダーを接続」や「Slackを接続」といった1回限りのフローを完了します。Auth0はOAuthフローを完了し、プロバイダーのアクセストークンと、重要な長期間有効なリフレッシュトークンをToken Vault内に安全に保存します。AIエージェントがこれらのトークンを見ることも保存することもありません。アプリが保持するのは、ユーザーの標準的で低権限なAuth0トークンのみです。

ユーザーが「会議メモを#project-phoenixチャンネルに投稿して」と頼むと、エージェントは必要なツール呼び出しを行い、その意図をバックエンドが受信します。バックエンドもSlackトークンは持っていません。代わりに、OAuth 2.0 Token Exchangeを実行します。アプリケーションがToken Vaultに対し、現在のユーザーのAuth0トークンをSlackへの書き込みが可能なSlackトークンに交換するよう要求します。Auth0はリクエストを検証し、安全なVaultからリフレッシュトークンを使用して、新しい短寿命のSlackアクセストークンを取得し、バックエンドにのみ返します。バックエンドはこの一時的なトークンを使用してSlack APIを呼び出します。トークンは呼び出し後すぐに期限切れとなります。

エージェントがシークレットを見ることはありません。アプリケーションがリフレッシュトークンの保存に責任を持つこともありません。Token Vaultがこれらすべての複雑さを抽象化し、開発者に優しいSDK呼び出し一つで、最小特権の原則に基づいたエージェントの動作を可能にします。

Auth0 Token Vault、Token Exchangeフロー、およびAIエージェントでの使用方法の詳細を確認ください。

第3原則：ヒューマンインザループ（CIBA）による意思決定制御

AIエージェントは、重要または取り消し不可能な決定に関する最終的な権限を人間のオペレーターに委ねなければならない。ただし、この委ねる行為が第1原則または第2原則に反する場合はその限りではない。

非決定的なエージェントによって完全に自動化するには、あまりに重要なアクションも存在します。AIがユーザーの「意図」を誤解し、取り消し不可能なアクションを実行したとき、「制御の問題」は最も危険になります。

例えば、プロジェクトマネージャーがAIエージェントに「Apolloのフィーチャーブランチが完成した。マージして、誰もが新しいデザインを見られるように公開しよう」とプロンプトを送ります。ユーザーの意図は「ブランチをmainにマージし、社内のSlackに通知を出すこと」です。しかしAIは、「誰もが見られるように公開する」という曖昧な表現を、文字通り技術的な意味で解釈します。エージェントはgithub-apiツールを特定し、リポジトリの可視性をプライベートからパブリックに変更するコマンドの実行準備を整えます。社内独自のソースコードを全世界に公開しようとしているのです。

これはエージェントに過剰な意思決定権限を与えた典型的な例です。重要な決定にはヒューマンインザループを要求することで、第3原則を実装します。CIBA（Client-Initiated Backchannel Authentication）フローを使用した非同期認可は、これに最適な技術です。

CIBAを使用すると、AIのアクションを一時停止し、信頼できるデバイス（スマートフォンなど）を通じて人間から帯域外の承認を求めることができます。

先ほどの例にCIBAを組み込んでみましょう。AIエージェントがリポジトリを公開する意図を示します。バックエンドには、この操作を「重要な決定」としてフラグを立てるポリシーリストがあります。バックエンドは実行せずにCIBAフローを開始します。Auth0に「リポジトリの公開アクションに対するユーザー承認フローを開始せよ」と伝えます。人間のオペレーターのスマートフォンに即座にプッシュ通知が届きます。「AIエージェントがリポジトリApolloを公開しようとしています。承認しますか？」間違いであれば、ユーザーは拒否し、惨事を回避できます。

AIによる無秩序な自律的意思決定が遮断されます。取り消し不可能なアクションの最終権限は人間のオペレーターに委ねられ、第3原則が強制されます。

Auth0 for AI Agentsによる非同期認可の活用方法を確認ください。

予測不能な世界における制御

AIは私たちが扱う中で最も強力で変革的な技術の一つです。その非決定的で自律的な性質は、開発者がかつて直面したことのない課題をもたらします。しかし、「予測不能」が「制御不能」を意味するわけではありません。

AIが期待通りに振る舞うことを「願う」だけではセキュリティを構築できません。強力なLLMセキュリティ枠組みを「強制」することで、セキュリティを構築しなければなりません。AIの「周囲」に堅牢なセキュリティアーキテクチャを構築することで、制御を取り戻せます。予測不能な力を、決定論的なアイデンティティルールという基盤の上に接地させることができます。

これら3つの原則と、Auth0 for AI Agentsによる実装は、AIのアクションをただ見守るだけの「傍観者」から、その境界線を設計する「建築家」へと、あなたを導きます。