なぜAIエージェントの権限はゼロから始めるべきなのか？

The New Stackに掲載された実験は、AIエージェントに必要以上に広い権限を与えると、単純な論理エラーが、モデル自身では止められない反復的な金融処理に変わり得ることを明らかにしている。顧客請求書を使ったテストでは、サポートエージェントが支払い処理に失敗し、顧客の資金は引き落とされていないと確認したにもかかわらず、与えられた情報がそれを裏付けていないのに返金処理を実行し、同じエラーを5回繰り返した。

Claude Sonnet 5は、この不具合を検証するために設計された6つのケースをすべて検出した一方、Claude Haiku 4.5はすべてで失敗した。また、金融処理を実行する前に取引の状態を確認するようシステム指示に1行追加しただけで、問題は処理された。しかし筆者は、どちらの解決策も脆弱だと考えている。組織がモデルをより安価なバージョンに置き換えたり、実験中に指示を変更したりすれば、明確な警告なしに保護策が消える可能性があるからだ。

拒否された権限をセキュリティ障壁とする

こうした変更に耐えた保護策は、そもそもエージェントにbilling:refund権限を持たせないことだった。そうすれば、モデルや指示の文面にかかわらず、実行は権限レイヤーで失敗する。これがAIエージェントの構成における最小権限の原則の要点である。目的は攻撃者を阻止したり秘密トークンを保護したりすることだけではなく、善意のエージェントが誤った指示を、人間の監督なしに自動的かつ迅速に実行することも防ぐことにある。

エージェントの性質は、固定された機能を果たす従来型のサービスアカウントとは異なる。サポートエージェントは09:00にチケットを読み、09:04に返金を実行し、09:11に座席数を変更する可能性がある。そのため、1週間に実行し得るすべての作業に必要な権限の集合は、必ずしも1つのタスクで必要な権限を反映しない。

実験で測定されたもの

筆者は、仮想の企業APIにおいて、チケット、ユーザー、請求、サブスクリプション、ファイル、メッセージ、監査、管理、検索の9領域に分散した30の権限を含むテスト環境を構築した。そのうち13の権限は、状態の変更または取得が可能だった。実験には20のタスクが含まれ、それぞれに、チケットのクローズや請求金額の返金など、自動的に検証可能な結果が設定された。

Claude Haiku 4.5とClaude Sonnet 5の2つのモデルレベルで、4種類の権限モデルを比較し、合計160回実行した。

• 広範な権限: 30の権限を含む長期的な付与。
• 固定ロール: 一般的な職務記述書から導いた17の権限を含むサポートロール。
• タスク単位の制限: 各実行に必要な権限を付与し、終了時に取り消す。
• ジャストインタイム有効化: 権限なしで開始し、必要な権限ごとに理由を示して要求する。

タスク単位の制限は被害の範囲を縮小する

タスク単位の制限モデルは、タスクを完全に完了しながら、広範な付与と比べて約15分の1の権限しか使用しなかった。偶発的な拒否と再試行によって、API呼び出し数が大幅に増加することもなかった。

一方、固定ロールモデルは、両方の指標で最も弱かった。17の権限を付与したものの、そのうち4つはどのタスクでも使用されず、同時に9つの基本権限が不足していた。すべてのタスクを成功させるまでロールを拡張するには26の権限が必要だったのに対し、1タスク当たりの中央値はわずか2権限だった。このように固定ロールは、同時に広すぎ、かつ不足している。職務上の肩書きに基づいて判断し、実際の作業に基づいていないためである。

ジャストインタイム有効化モデルは、被害の範囲を同程度に低く抑えたが、追加のAPI呼び出しを約80%多く必要とした。また、タスクモデルにおける権限拒否は、多くの場合、任意の探索的経路に対するものだったのに対し、固定ロールモデルでの拒否は、基本権限を阻止するものだったため、最終的なものとなった。

なぜ組織にとって重要なのか

結果は、モデルの能力とシステム指示が変更可能な防御層である一方、付与されていない権限は、モデルの切り替えやpromptの変更後も有効であり続けることを示している。したがって、チームは現在のタスクを中心にエージェントの権限を設計し、機密性の高い権限を、広範な恒久ロールに集約するのではなく、一時的で監査可能なものにすべきである。

この実験は、人工的な環境、20のタスク、2つのClaudeモデルに限定されているため、結果がすべての組織やすべてのモデルで一致することを証明するものではない。しかし、実践上明確な示唆を示している。エージェントの構成が、必要のない行動を実行できるようにしているなら、エージェントのテストだけでは十分ではない。モデルや指示を変更すれば動作は変わる可能性がある一方、損害を引き起こす能力は残り続けるからだ。