はじめに
AIエージェントの権限設計では、「利用者が見られるからエージェントも見てよい」と考えないことが出発点です。エージェントには専用の識別子を持たせ、対象データ、利用ツール、実行可能な操作、時間、承認条件を個別に制限します。人の権限をそのまま委任すると、誤操作の影響範囲と責任主体が見えなくなります。
NISTはAIエージェントが多様なデータやツールへアクセスする際、識別と認可の制御が必要だと論点化しています。OWASPのAgentic Applications Top 10でも、ツールの誤用とID・権限の悪用が主要リスクとして整理されています。
なぜ従来のユーザー権限だけでは足りないのか
一般的な業務システムは、人が画面を見て操作する前提で設計されています。AIエージェントはAPIやCLIを使い、複数の処理を短時間で連続実行できます。同じ権限でも、速度、反復回数、対象範囲が人とは異なります。
さらに、利用者の指示、外部文書、検索結果がエージェントの行動へ影響します。悪意ある入力や誤認識があっても、権限が広ければ実行できてしまいます。そのため、プロンプトの安全対策だけでなく、実行環境で権限を強制する必要があります。
権限設計の五つの層
1. エージェント専用ID
個人アカウントの認証情報を共有せず、エージェントごとに専用IDを発行します。誰の依頼で動いたかは別の属性として記録します。これにより、利用者、エージェント、実行先サービスを区別して追跡できます。
2. 最小権限
対象リソースと操作を絞ります。「全ファイルの編集」ではなく「指定フォルダの読取」、「顧客マスタの更新」ではなく「更新案の作成」といった粒度です。NISTのゼロトラストは、ネットワーク内にいることを信頼根拠にせず、アクセスの都度、主体とリソースに基づいて認証・認可する考え方を示しています。
3. 短期認証
長期間有効なAPIキーを置くのではなく、用途と期限を限定したトークンを使います。実行ジョブが終われば失効させ、再利用を難しくします。認証情報をプロンプトやログへ含めないことも重要です。
4. 操作別の承認
読み取り、下書き作成、外部送信、更新、削除を同じ扱いにしません。外部への送信、金額確定、削除、権限変更などは、実行直前に人または独立したポリシーエンジンで承認します。判断を人へ戻す設計は、AIエージェントとRPAの使い分けとも密接に関係します。
5. 緊急停止と失効
異常な回数、対象外リソースへのアクセス、連続失敗を検知したら停止します。停止時にトークンを失効し、未完了処理を一覧化し、必要なら元へ戻せる手順を用意します。
権限マトリクスを一枚作る
最初の成果物は、複雑なポリシーコードではなく権限マトリクスで構いません。
| 操作 | 自動実行 | 条件付き | 人の承認 |
|---|---|---|---|
| 社内文書の検索 | 対象フォルダ内 | 機密区分で制限 | 不要 |
| 回答案の作成 | 下書き保存まで | 個人情報を除外 | 不要 |
| 外部メール送信 | 不可 | 宛先と本文を固定 | 必須 |
| マスタ更新 | 不可 | 検証済み差分のみ | 必須 |
| 削除・権限変更 | 不可 | 緊急運用のみ | 二者承認 |
この表へ、利用ID、トークン期限、ログ保存先、停止条件を付ければ、実装と監査の共通言語になります。操作記録の具体項目はAIエージェントの証跡設計を参照してください。
実行チェックリスト
- エージェント専用IDを発行している
- 利用者IDと実行主体を区別して記録する
- 読取、作成、更新、削除の権限を分けている
- トークンに用途と期限がある
- 外部送信と不可逆操作に承認がある
- 認証情報を入力やログへ残さない
- 異常検知時に停止・失効できる
- 失敗した操作を復旧できる
まとめ
AIエージェントの安全性は、モデルが指示を守ることだけでは担保できません。専用ID、最小権限、短期認証、操作別承認、緊急停止を実行環境で強制し、誤った判断が大きな操作へ拡大しない構造を作る必要があります。まず一つの業務について権限マトリクスを作ることが、具体的な第一歩です。