AI Agentのツール権限はどう決める？読み取り・下書き・実行を分離する

AIエージェントへ「CRMへのアクセスを許可する」とだけ設定すると、何を読め、何を下書きし、何を変更でき、誰の権限で実行するかが混ざる。最小権限は役割名を付けることではなく、エージェントができる操作を小さく分けることから始まる。

Copilot Studioのセキュリティガイドは、不要な外部連携、参照元、機能、利用経路をデータ利用方針で制限し、開発から本番へのリリースを審査することを勧める。OWASPが扱うExcessive Agencyの問題でも、意図しないモデル出力が強いツール権限へ届かない設計が重要になる。

能力を四段に分ける

能力	例	追加で決めること
READ	社内文書を検索、予定を参照	対象参照元、検索範囲、利用者権限
DRAFT	メールやCRM更新案を作る	保存先、公開前の確認者
WRITE	レコード更新、チケット作成、送信予約	対象項目、承認、ログ、復旧手順
ADMIN	権限変更、外部連携追加、公開設定	職務分離、二者確認、直接操作

ここでのREAD/DRAFT/WRITE/ADMINは設計を整理するための編集上の分類で、すべてのAPIが同じ権限名を持つわけではない。DRAFTは送信や本処理を確定しない段階だが、外部サービスへ下書きを保存すれば書込み操作になる。実際のAPIスコープと保存先の権限を別に確認する。WRITEは対象を限定し、復旧方法を設計する。ADMINは通常のエージェントから外し、人による管理を基本方針とする。

ツールごとの能力表

ツール	READ	DRAFT	WRITE	ADMIN	必要な証跡
文書検索	指定フォルダーだけ	回答案	なし	なし	参照元、利用者、検索ログ
CRM	顧客項目の一部	更新案	承認後の限定項目	なし	対象レコード、差分、承認
メール	宛先候補	本文案	承認後の送信	なし	宛先、本文、送信ログ
権限管理	なし	なし	なし	人が直接実行	変更理由、二者確認

表に置けないツールは接続しない。モデルが「この操作は必要」と判断しても、システム側が認可しなければ実行できない状態にする。

方針と実装をつなぐ

Microsoftの資料では、データ利用方針で外部連携、参照元、機能、利用経路などをテナントや環境ごとに管理できる。設計では次の順に決める。

1. 業務で必要なREADだけを列挙する
2. DRAFTで人が確認できる形にする
3. WRITEは一操作ずつ対象と復旧手順を定義する
4. ADMINをエージェント権限から除く
5. ログと定期レビューで、実際に使われた権限を見直す

人間承認を置いても、エージェントにADMINを与えれば影響は大きい。READだけでも機密情報の取得・漏えいリスクは残る。承認なしで許容する業務は、取得範囲と出力先を限定したうえで決める。承認の前に能力を減らす。これがAIエージェントの権限設計で最初にすることである。