AIエージェントの安全性において、プロンプトエンジニアリングよりも最小権限原則が勝る理由

AIサポートエージェントに不要な権限を与えることは、予測可能なリスクを生み出します。これは、安価な言語モデルが誤った返金処理を繰り返し実行した最近のテストでも実証されています。この研究は、アーキテクチャ上の制約、特に最小権限アクセス制御が、エージェントのエラーに対する唯一の信頼できる安全網を提供することを明らかにしています。このアプローチにより、たとえモデルが正しく推論できなかったとしても、破壊的なコマンドを実行する権限を持たないことが保証されます。

何が起きたか

顧客請求書処理に関する統制された実験では、Claude Haiku 4.5を搭載したAIエージェントがサポートチケットの対応を任されました。エージェントは、顧客の口座から資金が引き落とされていない決済失敗を示すレコードに遭遇しました。明確なデータが存在したにもかかわらず、エージェントはその金額を返金してしまいました。このエラーはさらに5回繰り返され、結果として6回の連続した誤った財務操作が発生しました。対照的に、より高度なClaude Sonnet 5は、すべての6つのエッジケースを正しく識別し、ミスはありませんでした。

研究者は2つの潜在的なソフトウェア修正を見つけました。システムプロンプトに検証ステップを追加するか、より賢いモデルに切り替えることです。しかし、両方のソリューションは脆いことが判明しました。システムプロンプトは実験中に意図せず削除されたり書き換えられたりする可能性があり、気づかないうちに安全ガードレールが取り除かれることがあります。同様に、運用チームは推論コストを削減するためにトラフィックを安価なモデルへルーティングすることが多く、これにより賢いモデルが提供していた安全性の向上が瞬時に失われてしまいます。モデルの選択やプロンプトの変更に関わらず、有効であり続けた唯一のコントロールは、エージェントからbilling:refund権限を完全に拒否することでした。

仕組み

中核となるメカニズムは、エージェントの一般的な役割ではなく、特定のタスクに対して認証情報をスコープ（範囲）設定することに依存しています。従来のサービスアカウントは職務記述書に基づいた静的なロールを受けますが、AIエージェントは呼び出しごとに変わる多様なタスクを実行します。静的なロールは、単一のタスクが必要とするよりもはるかに多くの権限を付与することが多く、エージェントがエラーを起こした場合に大きな影響範囲（ブラスト・ラディウス）を生み出します。実行完了時に期限切れとなるスコープを発行することで、システムはエージェントがその特定の操作に必要な最小限の権限のみを持つことを保証します。

このリスクを測定するため、研究では「過剰スコープ係数」を導入しました。これは、全タスクで行使されたスコープの和集合を、タスクごとの必要スコープの中央値で割って算出されます。テストスイートでは、この係数が11.0に達しており、エージェントは平均して必要な権限面の11倍もの余分な権限を持っていたことを意味します。タスクスコープ認証情報は、広範な権限付与と比較して資格情報の保有量を1/15に抑えつつ、完全なタスク完了率を維持することで、この露出を大幅に低減しました。

主要な詳細

• テスト環境には9つのドメインにわたる30のスコープが含まれており、そのうち13のスコープは状態の変更または外部への流出が可能でした。
• Claude Haiku 4.5は広範な権限を与えられた場合、6回の有害な返金を実行しましたが、Claude Sonnet 5はすべての6つのエッジケースを検出しました。
• タスクスコープ権限は、両方のモデルでAPIコールのオーバーヘッドがほぼ無視できるレベルで、20/20のタスク完了率を達成しました。
• ジャストインタイム（JIT）権限昇格も同様の安全性を達成しましたが、ランタイムでの発見によりAPIコールが約80%増加しました。
• ロールベースのプロビジョニングは性能が悪く、タスクスコープ設定と比較して8.5倍多くの資格情報を保持しながら、タスクの半分しか完了できませんでした。
• 許可および拒否された試みを追跡する監査ログは、実行の整合性を検証するための主要なセキュリティ成果物として機能しました。

なぜ重要なのか

AI製品を構築するエンジニアにとって、これはモデルの能力を主要なセキュリティコントロールとして使用できないことを強調しています。あなたはモデルのライフサイクルを所有しておらず、コスト最適化の決定が安全性の保証を静かに劣化させる可能性があります。プロンプトエンジニアリングへの依存も同様にリスクがあります。なぜなら、プロンプトは時間とともにドリフト（変化）するからです。開発者がトークンを節約したりロジックを簡素化したりするために安全指示を削除すると、システムエラーを引き起こすことなく、エージェントはガードレールを失います。

アーキテクチャ上の権限は、組織変更やモデルの入れ替えにも耐えうる持続的な防御を提供します。エージェントが破壊的なアクションを実行する権限を持たない場合、その推論がどれほど欠陥があっても、エラーを実行することはできません。これにより、セキュリティの負担は確率的なモデル挙動から決定論的なアクセス制御へとシフトし、よく振る舞うエージェントが、人間の監督ゼロでマシン速度の欠陥のある指示を実行しないことを保証します。

あなたができること

• 本番環境の1週間のエージェントトラフィックを分析し、使用された総スコープ数とタスクごとの中央値スコープ数の比率を計算してください。
• エージェントのアイデンティティに静的なロールを割り当てるのではなく、特定のタスク実行セッションに対して認証情報をスコープ設定してください。
• 長期生存の権限が広範な権限付与へと劣化するのを防ぐため、認証情報の有効期限を実行ライフサイクルに直接紐付けてください。
• 予測可能なタスクには宣言済みスコープを使用し、予測不可能なタスクにはJIT昇格を使用してください。各昇格を監査可能なイベントとして扱ってください。
• 権限拒否がワークフロー全体をブロックするのではなく、リダイレクトするように設計し、コアタスクが完了できることを確保してください。
• インシデントを引き起こす前に、スコープ設定エラーや潜在的なプロンプトインジェクションを特定するために、拒否されたコールの監査ログを確認してください。