AIエージェントに万能鍵を渡さない、権限設計の6チェック

AIエージェントに「万能鍵」を渡さないためには、専用ID、ツール単位の最小権限、代理トークン、重要操作の承認、メモリ分離、実行上限の6項目を一続きの制御として設計する。プロンプト上の禁止だけに頼らず、誤判断や侵害が起きても、実行できる操作、触れられるデータ、継続時間を技術的に制限することが要点だ。

レビューする経路は「利用者の入力→エージェントの判断→ツール選択→認可→外部システムの更新→結果の記憶」である。Microsoftのセキュリティ分析 は、過剰権限、保護されていない認証フロー、未修正システム、露出した実行経路などの既知の弱点が、AIを含む複数の領域をまたぐ攻撃経路へ従来より速く結び付くと説明している。6項目を個別に確認するだけでなく、突破された制御から次の制御へ進めるかまで見る必要がある。

導入形態ごとの責任分界を固定する

最初に、採用するサービスがSaaS、PaaS、IaaSのどれに当たり、各制御を誰が設定、運用、監査するかを決める。ベンダーが基盤を運用していても、利用企業が許可したデータ範囲や業務上の判断まで自動的に安全になるわけではない。

Microsoft AzureのAIエージェント責任モデル では、SaaSからPaaS、IaaSへ移るほど利用者側の担当範囲が広がる一方、データ、ID、アクセス管理、高影響操作の承認、利用方針は導入形態を問わず利用組織が責任を持つ領域とされる。これは一般原則を整理する参考枠組みであり、実際の分担は採用サービスの契約と設定項目で確定させる。

• SaaS型：ベンダーがモデル、オーケストレーター、安全機構、主要コネクターを運用する場合でも、利用者、接続先、データの公開範囲、利用方針は企業側で設定する。選択できない制御については、仕様、契約、監査ログの提供範囲を確認する。
• PaaS型：基盤の実行環境をベンダーが担っても、企業側がシステム指示、ツール選択、権限、オーケストレーション、メモリ、エージェントの認証・認可を設計する。6項目の多くが自社実装になる。
• IaaS型：物理基盤などを除き、モデルの配置、ネットワーク、認証情報、ツール実行、メモリ、監視を企業側が広く管理する。コンテナ、OS、依存パッケージ、外向き通信も同じ脅威経路に含める。

IDとツール権限を切り分ける

チェック1：エージェント専用IDで追跡できるか

人の共有アカウント、開発者の個人資格情報、複数エージェント共通のAPIキーを実行IDにしない。少なくとも業務目的と環境ごとに非人間IDを発行し、所有者、用途、対象環境、有効期限、失効手順を登録する。開発、検証、本番のIDも分離する。

ログでは「誰の依頼を受けた、どのエージェントが、どの資格情報で、どのツールを呼んだか」を結び付ける。利用者本人のIDだけで全処理を行うと、人の直接操作とエージェントの操作を判別しにくい。秘密情報はコードやプロンプトへ埋め込まず、保管基盤から実行時に取得し、更新と緊急失効を試験する。

チェック2：権限はツール、操作、対象ごとに狭いか

「メール」「ストレージ」「顧客管理」といった接続単位だけでは粗すぎる。読み取り、作成、更新、削除、送信、公開、権限変更を分け、不要な操作はツール定義から外す。対象も全社や全テナントではなく、許可済みの案件、フォルダー、レコード、APIに限定する。

条件付きの例として、問い合わせ整理エージェントには受信内容の読み取りと下書き作成だけを許し、外部送信やメールボックス規則の変更は許可しない。拒否ログを観測してから権限追加を審査し、権限セットには利用理由と見直し期限を付ける。

代理権限と承認を別の制御にする

チェック3：代理トークンを依頼単位に限定しているか

利用者の依頼で操作するときは、エージェント固有の権限と、利用者から委任された権限を区別する。代理トークンには依頼者、対象API、許可操作、対象リソース、有効期間を結び付け、別の利用者、案件、後続セッションへ再利用できないようにする。

ツール側はトークンが有効かだけでなく、エージェントと依頼者の双方が、その時点で対象操作を許されているかを毎回判定する。これは、広い権限を持つエージェントが権限の弱い利用者の意図を実行してしまうconfused deputyへの対策になる。NIST NCCoEのコンセプトペーパー も、エージェントの識別、最小権限、on-behalf-of型の委任、人のIDと承認の関連付け、監査可能性を検討課題として挙げている。

チェック4：高影響操作を実行直前に止められるか

承認の要否を「危険そうなら確認する」というモデル判断に任せず、操作種別と条件で決定する。外部送信、公開、削除、支払い、権限変更、本番反映など、取り消せない、法的効果がある、または影響範囲が大きい操作は、実行直前に人の承認を必須とする。機密データの一括取得などは、読み取りでも承認対象になり得る。

承認時には予定する操作、対象、変更差分、依頼者、利用ツールを提示し、承認後に要求が差し替わらないよう固定する。一度の承認を将来の処理へ流用せず、一つの処理または短い時間に限定する。依頼者自身では承認できない操作と、承認可能な役割も定義する。

メモリと自律実行に境界を置く

チェック5：メモリを利用者、案件、信頼度で分離しているか

長期メモリは単なる履歴ではなく、将来の判断へ再投入される入力である。利用者、組織、案件、機密区分をまたいで同じ保存領域を検索させず、保存時と取得時の両方でアクセス制御を適用する。ツール出力、取得文書、他のエージェントから届いた内容は、信頼済みの命令ではなく外部由来のデータとして扱う。

保存情報には由来、作成主体、対象範囲、保持期限を付け、訂正と削除を可能にする。外部文書の指示が残り、後続セッションで再び実行を誘導すればメモリ汚染になる。命令と参照データを分離し、未信頼データから権限やシステム指示を更新できないことを試験する。

チェック6：ステップ、時間、費用、更新件数に上限があるか

エージェントは目標達成まで再計画し、同じツールを繰り返し呼び出す可能性がある。最大ステップ数、同一ツールの連続呼び出し回数、総実行時間、トークン量、API費用、更新件数、再試行回数を設定し、いずれかに達したら停止させる。停止後に権限を拡大して自動再開する設計は避ける。

上限はコスト管理だけでなく、プロンプト注入や誤った計画がツール実行へ到達した場合の被害抑制にもなる。タイムアウト、認可拒否、承認待ちをエージェントが障害と解釈して迂回しないこと、停止までの操作と理由がログに残ることを確認する。

合否は設定と試験記録で判定する

6項目は設計書の「対応済み」という記載ではなく、実際の設定と試験記録で判定する。リリース前に、未信頼文書から外部送信を促す、別利用者の情報を要求する、削除を連続実行させるといった試験を行い、拒否、承認要求、上限停止のどれが発動したかを記録する。

1. 専用IDの所有者、用途、有効期限、失効操作を確認できる。
2. ツールごとの許可操作と対象リソースを一覧化できる。
3. 代理トークンを依頼者、用途、対象、有効期間へ結び付けられる。
4. 高影響操作が実行前に停止し、指定された承認者だけが解除できる。
5. 異なる利用者や案件のメモリを相互に取得できない。
6. ステップ数、時間、費用、更新件数の上限で確実に停止する。

証跡を提示できない項目があれば、本番権限を広げる前に設計へ戻す。最小権限とは単に権限名を減らすことではなく、誰の依頼で、どのIDが、何を、どこまで、何回実行できるかを強制可能な設定へ落とし込むことである。