生成AIが「答える」だけの段階では、誤りは文章の誤りでした。エージェントとして外部システムを操作できるようになると、同じ誤りが「実行された操作」になります。この記事では、AIエージェントへ与える操作権限を、機能・権限・自律性という3つの軸に分けて設計する手順を整理します。
対象は、情報システム、セキュリティ担当、AI導入責任者、業務のオーナーです。ゼロリスクの保証、特定製品の設定手順、侵入テスト、プロンプトインジェクションの全体解説、適合認証は扱いません。攻撃手口そのものはプロンプトインジェクション攻撃の実務リスクで扱っています。
1. 「答えるAI」と「動けるAI」では、リスクの性質が違う
OWASP の GenAI Security Project は、LLM を組み込んだシステムについて 「An LLM-based system is often granted a degree of agency by its developer - the ability to call functions or interface with other systems via extensions (sometimes referred to as tools, skills or plugins by different vendors) to undertake actions in response to a prompt.」（LLM ベースのシステムには、プロンプトに応じて動作を行うために、関数を呼び出したり拡張機能を通じて他システムと接続したりする能力が、開発者によってしばしば付与される）と説明しています。
ここで変わるのは、誤りの現れ方です。
| 段階 | 誤りの現れ方 | 取り消せるか |
|---|---|---|
| 答えるだけ | 誤った文章が出力される | 採用しなければ影響なし |
| 下書きを作る | 誤った内容がファイルとして残る | 破棄できる |
| 更新する | 既存データが書き換わる | 版管理があれば戻せる |
| 送信・公開する | 社外の相手に届く | 相手が受け取った後の完全な回収は難しい |
| 削除する | データが消える | バックアップ次第 |
2. 機能・権限・自律性を別の軸として分ける
OWASP は、過剰なエージェンシー（Excessive Agency＝AIに与えた「動ける範囲」が広すぎる状態）の根本原因として excessive functionality（過剰な機能）、excessive permissions（過剰な権限）、excessive autonomy（過剰な自律性）の3つを挙げています。本稿ではこの3つを独立した軸として扱います。どれか1つを絞っても、他が広いままなら影響は残るためです。
- 機能：そもそも何ができる状態にしてあるか。使わない機能が有効なままになっていないか
- 権限：その機能が、どの範囲のデータやシステムに対して働くか
- 自律性：人の確認を挟まずに、どこまで自分で実行してよいか
混同しやすいのは機能と自律性です。「メール送信機能を持っている」ことと「人の確認なしに送信できる」ことは別です。機能を残したまま自律性だけ下げる、という設計が取れます。
3. 操作を6種類に分けて棚卸しする
権限を「読み取り／書き込み」の2分類で扱うと、送信と更新が同じ箱に入ってしまいます。本稿では実務上の整理として6種類に分けます。
| 操作 | 内容 | 既定の扱い |
|---|---|---|
| read | 参照する | 対象を限定して許可。記録は残す |
| draft | 下書きを作る | 作成先を限定して許可 |
| update | 既存を書き換える | 対象限定。影響が大きければ承認 |
| send | 外部へ送る・公開する（外部作用あり） | 影響の大きさと可逆性で承認の要否を判断する |
| execute | 外部システムを動かす（外部作用あり） | 影響の大きさと可逆性で承認の要否を判断する |
| delete | 消す | 復旧手段の有無で判断。復旧が難しければ承認を置く |
この6分類は本記事の実務整理です
OWASP や NIST がこの6分類を規定しているわけではありません。自社の業務に合わせて増減させてください。分ける目的は、「書き込み権限」という一語に、取り消せる操作と取り消せない操作を同居させないことです。
なお、ファイルの保存先や公開操作を伴うツール（図解作成ツールなど）では、send と execute の承認点が公開判断そのものになります。公開前に何を確認するかは生成AIで図解を作る実務フローで扱っています。
最小権限という考え方
OWASP は対策として 「Minimize extension functionality: Limit the functions that are implemented in LLM extensions to the minimum necessary.」（拡張機能に実装する機能を必要最小限に限定する）および 「Minimize extension permissions: Limit the permissions that LLM extensions are granted to other systems to the minimum necessary in order to limit the scope of undesirable actions.」（望ましくない動作の範囲を限定するため、拡張機能に与える他システムへの権限を必要最小限に限定する）を挙げています。必要最小限に限るという原則が、機能と権限の双方に適用されます。
この原則は情報セキュリティ一般で「最小権限」と呼ばれ、NIST が公表する 『Security and Privacy Controls for Information Systems and Organizations』（NIST SP 800-53 Rev. 5、2020年9月／2020年12月10日時点の更新を含む）のような管理策カタログにも位置づけられています。
4. 利用者本人の権限文脈で実行する
エージェントに共通のサービスアカウントを持たせると、誰が依頼しても、そのアカウントに与えられた権限で動きます。依頼者ごとの権限差は反映されません。OWASP は 「Execute extensions in user's context: Track user authorization and security scope to ensure actions taken on behalf of a user are executed on downstream systems in the context of that specific user, and with the minimum privileges necessary.」（利用者の権限と適用範囲を追跡し、その利用者の代理として行う操作が、下流システムでもその利用者の文脈で、かつ必要最小限の権限で実行されるようにする）と述べています。
実務では次を確認します。
- エージェントは誰の権限で下流システムへアクセスしているか
- 依頼した利用者が本来アクセスできない範囲へ、エージェント経由で到達できてしまわないか
- 利用者の権限が変わったとき、エージェント側にいつ反映されるか
5. 高影響の操作に人の承認を置く
OWASP は 「Require user approval: Utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken.」（高影響の操作は、実行前に人が承認するよう human-in-the-loop の制御を用いる）と述べています。対象が「高影響の操作」に限られている点が重要です。
すべての操作に承認を置くと、承認が形骸化します。承認点は次の3つで決めます。
| 判断軸 | 問い | 承認を置く例 |
|---|---|---|
| 影響 | 誤ったとき誰にどこまで及ぶか | 社外送信、公開、購入 |
| 可逆性 | 取り消せるか、どれだけの手間で戻せるか | 削除、権限変更 |
| 外部作用 | 自社の外に作用するか | メール送信、API 経由の発注 |
許可の判断をモデルに委ねない
OWASP は 「Complete mediation: Implement authorization in downstream systems rather than relying on an LLM to decide if an action is allowed or not.」（操作が許可されるかどうかを LLM に判断させるのではなく、下流システム側で認可を実装する）と述べています。
モデルが「この操作は許可されています」と答えたことは、アクセス制御ではありません。判断は下流システムの認可機構が行い、モデルの出力はその入力に過ぎない、という位置づけを崩さないことです。
6. 開放的な機能を避ける
OWASP は 「Avoid open-ended extensions where possible (e.g., run a shell command, fetch a URL, etc.)」（任意のシェルコマンド実行や任意 URL の取得のような、開放的な拡張機能は可能な限り避ける）と述べています。
「何でもできる」機能は、権限の棚卸しが成立しません。何ができるかを列挙できないためです。代わりに、用途を限定した個別の機能を用意します。任意 URL 取得ではなく特定ドメインのみ、任意コマンド実行ではなく定義済みの処理のみ、という形です。
なお、ここに挙げたシェルコマンドや URL 取得は例示であり、すべての製品が同じ実装を持つという意味ではありません。自社が使う製品の機能一覧を実際に確認してください。
7. 記録・通知・失効を運用に組み込む
OWASP は、拡張機能と下流システムの活動を記録・監視すること、およびレート制限を実装することについて、被害の程度を限定しうる（can limit the level of damage caused）が、過剰なエージェンシーそのものを防ぐわけではないと位置づけています。
ログとレート制限は「予防策」ではありません
これらは起きたことを検知し、被害の広がりを抑えるための仕組みです。「ログを取っているから安全」「レート制限があるから大丈夫」という説明は成立しません。過剰な権限そのものを絞る作業の代わりにはなりません。
あわせて、本稿が参照している OWASP Top 10 は啓発を目的としたガイダンスであり、認証規格でも法的なセーフハーバーでもありません。記載された対策を実施したことをもって安全・適法とみなすことはできません。
運用設計には、記録に加えて次を入れます。
- 通知：高影響の操作が実行されたら、事後でも関係者に届く
- 即時失効：異常に気づいたとき、エージェントの権限をその場で止められる経路と担当
- 棚卸しの周期：付与した権限を定期的に見直す。使われていない権限は外す
8. 負例：広いサービスアカウントと一括承認
| よくある設計 | 何が起きるか | 代わりにすること |
|---|---|---|
| 共通のサービスアカウントに広い権限を付与 | 誰の依頼でも最大権限で動き、事故時に影響範囲を特定できない | 利用者の権限文脈で実行し、対象を限定する |
| 初回に「すべて許可」を一括承認 | 以後の高影響操作が無確認で通る | 影響・可逆性・外部作用で承認点を分ける |
| 読み取り権限だから安全とみなす | 参照した機密が出力経由で外部へ出る | read でも対象範囲を限定し、記録を残す |
| 試験用の広い権限を本番へ持ち込む | 不要な権限が恒久化する | 試験と本番で権限を分け、期限を付ける |
9. 権限一覧表（permission matrix）を作る
人と情報区分の側の権限（誰が、どの機密度の情報をどの環境で扱えるか）はAIに渡す情報の管理と権限設計で整理しています。本稿の表は、エージェントが行う操作の側を並べたものです。両方を突き合わせると、抜けが見つかります。
棚卸しの成果物は1枚の表です。列は固定し、行に操作を並べます。
| 列 | 記入内容 |
|---|---|
| 操作 | read / draft / update / send / execute / delete |
| 対象 | どのシステムの、どの範囲か |
| 必要権限 | その操作に最低限必要な権限 |
| 実行文脈 | 利用者本人か、サービスアカウントか |
| 承認 | 不要／事前承認／事後通知 |
| 記録 | 何をログに残すか |
| 失効 | 止める経路と担当、期限 |
既定は default deny、つまり「表に書いていない操作はできない」状態から始めます。必要になったら1行ずつ足すほうが、広く与えてから削るより確実です。広く与えてから削る方式は、どの権限が実際に使われているかを判別できないまま「念のため残す」判断に流れやすく、結果として絞り込みが進みません。
表は一度作って終わりにせず、担当者と見直し時期を欄外に書いておきます。エージェントの機能追加、業務範囲の拡大、担当者の交代は、いずれも表の前提を変えます。見直しの契機が決まっていない表は、時間が経つほど実態と離れます。
まとめ
AIエージェントの権限設計は、機能・権限・自律性を分け、操作の種類ごとに必要権限と承認点を決め、記録と失効の経路を用意する作業です。難しいのは技術ではなく、「この操作は取り消せるか」を1件ずつ判断するところにあります。
最後に区別を1つ。権限設計は影響範囲を限定しますが、プロンプトインジェクションや誤回答そのものを消すものではありません。誘導された指示が実行されても被害が小さくて済む、という性質の対策です。攻撃を受けない設計ではなく、受けても止まる設計だと考えてください。
まずは自社で使っているエージェントについて、6種類の操作のうちどれが実際に有効になっているかを確認するところから始めてください。使っていない操作が有効なままなら、そこが最初に絞る対象です。
引用元・参考文献
公式ガイダンス・標準
- OWASP GenAI Security Project『LLM06:2025 Excessive Agency』（機能・権限・自律性の3要素、最小化、利用者文脈での実行、高影響操作の人による承認、下流システムでの認可、ログとレート制限の位置づけ／確認日：2026年8月11日）：https://owasp.org/www-project-top-10-for-large-language-model-applications/2_0_vulns/LLM06_ExcessiveAgency.html
- NIST『Security and Privacy Controls for Information Systems and Organizations』（NIST SP 800-53 Rev. 5、2020年9月／2020年12月10日時点の更新を含む。管理策カタログの最新マイナーリリースは Release 5.2.0、2025年8月27日。出版物としての参照／確認日：2026年8月11日）：https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
※ 最小権限に関する本文の記述は、OWASP の「必要最小限に限定する」という記述を直接の根拠としています。NIST SP 800-53 は出版物として参照しており、個々の管理策の条文を引用したものではありません。read / draft / update / send / execute / delete の6分類、承認点を影響・可逆性・外部作用で決める整理、permission matrix の列構成は本記事による実務整理であり、OWASP や NIST が規定した分類ではありません。OWASP Top 10 は啓発を目的としたガイダンスであり、認証規格や法的なセーフハーバーではないため、「OWASP 準拠だから安全」といった表現は用いていません。掲載資料は改定されるため、参照時は最新版をご確認ください。