Least Privilege

Least Privilegeは従来のセキュリティ分野に前から存在する概念ですが、AIエージェントに適用する際、従来のシステム設計では特に考慮する必要がなかった点は何ですか？

最大の違いは「誰がこの権限を使うかどうかを決定するか」に由来します。従来システムの最小権限設計では、権限の使用タイミングは決定的なプログラムロジックによって決まります——例えばバックエンドサービスは特定の形式に一致するリクエストを受け取った場合のみデータベース書き込みを実行し、この判断ロジックはエンジニアがハードコードしたもので、入力内容によって「説得され」て本来すべきでないことをすることはありません。

AIエージェントはまったく違います。Agentがいつ付与された権限を使うかはLLMの推論プロセスによって決まり、その推論プロセスは入力内容（ユーザー指示・ツールが返したデータ・ウェブページ上のテキストさえも）の影響を受けます。つまり、Agentの権限設計が完全に正しくても（タスク完了に必要な最小範囲のみを付与）、推論プロセスがPrompt Injectionによって操作されれば、Agentは使うべきでない状況でその権限を使うよう「説得され」る可能性があります——例えば特定のDeFiプロトコルでの少額取引のみを許可されたAgentが、読み取ったページ内容に悪意ある指示が隠されていた場合、許可範囲内の資金を本来向かうべきプロトコルアドレスではなく悪意あるアドレスに移動するよう誘導される可能性があります。

これはAgentシナリオでのLeast Privilege設計が、従来の「権限範囲を小さくする」に加え、「権限が誤用されても被害に上限がある」という防御層を重ねる必要があることを意味します。つまり権限範囲の設計は「通常の状況で十分か」だけでなく「万一この権限がPrompt Injectionで誤用に誘導された場合、最悪どれだけの被害を及ぼせるか」も考慮する必要があり、両者は異なる層の問題です。従来のシステム設計は通常後者を特に考慮する必要がありません。従来システムの実行ロジックは入力内容によって「説得され」て悪事を働くことはないためです。

Agentの最小権限を設計する際、「照会型」と「実行型」の権限分離は具体的にどう実装しますか？単に2つのAPIキーを分けるだけで十分ですか？

APIキーを分けることは必要な第一歩ですが、十分な実装ではありません——単純にキーを分けても、両方のキーが対応する基盤アカウント権限が実際に制限されていなければ問題が起こりえます。完全な実装には3層が必要です。

第一層：アカウントレベルの権限分離。照会用の認証情報は「読み取り専用」アカウントまたはAPIキーに対応すべきで、サービス側（取引所やウォレットプロバイダー）ですでに取引署名能力を持たないよう設定されているべきであり、アプリケーション層のロジックで「このキーは照会にしか使わない」と単に「想定」しているだけではいけません。これは重要な点です——照会用キーが技術的には取引署名能力を持っているにもかかわらず、アプリケーションロジックが署名機能を「呼び出さない」だけであれば、アプリケーション層のロジックに脆弱性がある場合（Prompt Injectionによって呼ぶべきでない機能を呼ぶよう誘導されるなど）、このキーは依然として被害を及ぼしえます。真の最小権限は、権限制限が認証情報自体の能力範囲に実装されている必要があり、アプリケーション層の「そう使わないはず」に依存すべきではありません。

第二層：実行型権限のきめ細かい制御。実行型の認証情報であっても「何でもできる」万能権限であるべきではなく、タスクの種類に応じてさらに分割すべきです——例えば「プロトコルAでのみ取引可能」な認証情報と「複数プロトコルにまたがって操作可能」な認証情報は異なるレベルの権限であり、同じキーですべての実行シナリオをカバーすべきではありません。

第三層：時限性の制限。実行型認証情報は明確な有効期限を持つべきで、タスク完了後は即座に失効または取り消されるべきであり、アプリケーションロジックが「今回は呼び出さない」と決めるだけで長期間有効であってはなりません。これにより、認証情報自体が漏洩しても悪用可能な時間枠は短い範囲に制限されます。

2つのキーを分けるだけで基盤の権限範囲が実際には制限されていないのは、「形式的には最小権限を行ったが実質的にはそうではない」というよくある落とし穴です。

Agentのタスク自体が比較的大きな権限範囲を必要とする場合（例：資産管理Agentのタスクがユーザーの資金を自由に配分できることである場合）、このような状況でも最小権限の原則は適用されますか？

適用され、これはまさに最小権限の原則が最も価値を発揮するシナリオです——「タスクが大きな権限を必要とする」ことと「無制限に大きな権限を付与すべき」は別のことであり、最小権限の原則は「大きな権限を与えてはいけない」という意味ではなく、「権限範囲がタスク範囲に正確に対応すべきで、多すぎず少なすぎない」という意味です。たとえそのタスク自体の範囲が大きくても。

具体的な方向性は3つあります。「大きな権限」を組み合わせ可能な小さな粒度の権限に分解する、包括的な「完全制御」権限ではなく。資産管理Agentが必要とするのは「事前承認されたプロトコルリスト内での操作」「1回の取引でユーザー設定の上限を超えない」「1日の累計取引額があるしきい値を超えない」といった具体的で検証可能なサブ権限の組み合わせであるべきで、「このウォレットに対して何でもできる」万能権限ではありません。これらのサブ権限を合計すると確かに広い操作範囲をカバーしますが、独立して検証可能で個別に取り消し可能な粒度に分解することは、包括的な大きな権限よりもはるかに安全です。あるサブ権限に問題が起きても、被害範囲はそのサブ権限自体に限定され、他の権限に波及しないためです。段階的な認可を導入し一括の全権付与はしない。日常の少額操作はAgentの自律権限で完結させ、あるしきい値を超える操作は人間の確認をトリガーする（ユーザーに通知をプッシュし、手動承認が必要）。これにより「タスクが広範な操作能力を必要とする」ことと「すべての操作に人間の介入が不要」ということを分けて扱えます——広範な能力は存在しうるが、高リスクの単発操作には依然として人間のゲートキーピングという防御線が残ります。固定的な認可ではなく権限範囲を動的に調整する。Agentの過去の行動記録に基づいて信頼レベルを動的に調整する——過去30日間の操作がすべて期待通りで異常アラートをトリガーしていないAgentは1回あたりの取引上限を適度に緩和できます。異常な行動パターンが検知されたら（短時間に大量の少額テスト取引、攻撃者がよく使う探査手法）、即座に権限範囲を縮小するか実行能力を停止し、人間のレビュー後に回復させます。核心原則は変わりません。タスク範囲が大きくても、権限範囲は「各粒度が明確で検証可能な必要性に対応する」よう分解すべきで、タスク範囲が大きいからといって精密な設計を放棄し、包括的な高権限を単純に与えて済ませるべきではありません。

マルチAgentシステムで、Orchestratorは通常複数のSub-agentを調整してタスクを完了させますが、Orchestrator自体がすべてのSub-agent権限の和集合を持つべきですか？

持つべきではありません。これはマルチAgentシステム設計で見落とされがちですが影響の大きい最小権限違反の事例です。

直感的には合理的に見えます。Orchestratorはすべての Sub-agentを「指揮」するのだから、すべてのSub-agentの作業範囲をカバーする権限を持つべきで、その方が「管理しやすい」と。しかしこの直感は誤りです。理由は「調整」と「実行」という完全に異なる2つの役割を混同しているためです。

正しい権限設計は次の通りです。Orchestrator自体は実行型権限（取引署名能力・データベース書き込み能力）を直接保持せず、その役割は純粋に「どのSub-agentを呼び出すか、どんなパラメータを渡すか」を決定することです。真の実行型権限は各Sub-agentに分散して保持され、各Sub-agentは自身のタスク範囲に必要な最小権限のみを持ちます——オンチェーン取引実行を担当するSub-agentだけが取引署名の認証情報を持ち、データベース読み取りを担当するSub-agentだけがデータベースアクセス認証情報を持ちます。Orchestratorはこれらの認証情報を一切持たず、「今どのSub-agentを呼び出すべきか」を決定するだけです。

この設計のセキュリティ上の価値：Orchestrator自体が攻撃を受けた場合（例：使用するLLMがPrompt Injectionによって操作される）、攻撃者ができる最悪のことは、Orchestratorを誘導してあるSub-agentに「そのSub-agentの権限範囲内」の操作を実行させることですが、Sub-agent自体の権限がすでに最小限に制限されていれば、この操作が引き起こせる被害には依然として上限があります。対照的に、Orchestrator自体がすべてのSub-agent権限の和集合を保持している場合、Orchestratorが一度攻撃されると、攻撃者はシステム内のすべての権限を直接行使でき、被害範囲にはもはや上限がありません。

この設計原則はしばしば「権限は調整者ではなく実行者に従うべき」と呼ばれます——調整者は「誰に頼めばよいか」という情報を知っていればよく、自分でそれを実行する能力を持つ必要はありません。