メールを要約させるだけのつもりで導入したエージェントが、実は送信機能も持っていた。攻撃者が仕込んだ一通のメールで、受信箱の内容が外部へ転送される。OWASPが示す典型シナリオです。
中小企業では専任のセキュリティ担当がおらず、エージェントに何を持たせたかを誰も一覧にしていないことが少なくありません。本記事では、エージェントガバナンスの入口として、Excessive Agencyを3軸で棚卸しする手順を整理します。あわせてAIエージェントの台帳づくりの最小スキーマと組み合わせると、点検対象の洗い出しが楽になります。
Excessive Agencyとは何か
OWASP Top 10 for LLM Applications 2025のLLM06は、想定外の出力で有害な操作が実行されてしまう脆弱性を指します。
OWASPの定義では、幻覚・性能不足・プロンプトインジェクション・侵害された拡張機能や他のエージェントなど、原因を問わず、モデルの曖昧または操作された出力によって損害のある操作が起きる状態を指します。モデルの出力検証不足を扱う Improper Output Handling とは別の項目です。
原因は3つに整理されています。
- 過剰な機能: エージェントに不要な拡張機能や関数が付いている
- 過剰な権限: 拡張機能が下流システムに対して、タスクに必要な以上の権限を持つ
- 過剰な自律性: 影響の大きい操作が、人間の承認や独立した検証なしに進む
機能の軸では何を点検するか
機能の軸では、エージェントが持つツールを一覧にし、業務に不要なものを外します。OWASPは汎用的なシェルやURL取得の回避を推奨しています。
点検の手順は次のとおりです。
- エージェントごとに、接続しているツール・MCPサーバー・拡張機能を書き出す
- ツールごとに、公開している関数（読む・書く・削除する・送る）を列挙する
- 業務フローで実際に使う関数だけを残し、残りは無効化する
- シェル実行や任意URL取得のような汎用ツールは、用途を絞った専用ツールに置き換える
OWASPの例では、メール要約が目的なら読み取り関数だけを公開し、送信や削除は持たせません。外す判断に迷ったら「このエージェントが書き込めなくなると業務が止まるか」を基準にします。
権限の軸では何を点検するか
権限の軸では、ツールが下流システムに持つ権限を最小化します。OWASPの例では、メールは読み取り専用のOAuthスコープで接続します。
機能を絞っても、裏側の認証情報が広ければ意味がありません。次の3点を確認します。
- データベースは読み取り専用ユーザーで接続しているか
- OAuthのスコープは、必要な操作だけに絞られているか
- 共有の管理者アカウントではなく、操作する利用者本人の権限で動いているか
さらに、許可の判断をモデルに任せないことが重要です。OWASPはcomplete mediation（完全な仲介）として、下流システム側が全リクエストをセキュリティポリシーに照らして検証することを求めています。認証情報の設計はスコープ付き短命認証情報も参照してください。
自律性の軸では何を点検するか
自律性の軸では、送信・削除・支払いなど影響の大きい操作を洗い出し、実行前に人間の承認を挟みます。
承認を挟む対象は、取り消しにくい操作に絞ります。全操作を承認制にすると承認が形骸化するため、次のように分けます。
| 区分 | 例 | 扱い |
|---|---|---|
| 読み取り | 検索・要約・参照 | 自動実行 |
| 可逆な書き込み | 下書き作成・社内メモ更新 | 自動実行＋ログ |
| 不可逆・社外影響 | メール送信・削除・支払い | 人間の承認が必須 |
OWASPは、ミスを完全には防げない前提で被害を抑える策も挙げています。拡張機能と下流システムの活動をログに記録して監視すること、レート制限で一定期間に起こせる望ましくない操作の数を抑えることです。
Claude Codeではどこで強制するか
Claude Codeでは、deny→ask→allowの順に評価されるルールで、機能と権限の制限を設定ファイルに固定できます。
Claude Codeの公式ドキュメントによると、権限ルールはdeny、ask、allowの順に評価され、最初に一致したものが結果を決めます。PreToolUseフックがallowを返しても、denyルールは破られません。また、Bashのルールはコマンド文字列に対するもので、同じプログラムを別の形で呼ぶ場合までは止められないため、denyルールは境界の代わりにはなりません。実行環境の隔離と併用します。
承認の仕組みを設計する場合は、ヒューマン・イン・ザ・ループ設計が参考になります。
規模別の運用の始め方
最初の1回は、最も権限の広いエージェント1つに絞って3軸を点検し、結果を台帳に残します。
全エージェントを一度に点検する必要はありません。社外へ送信できるもの、顧客データを読めるものを優先し、1エージェントずつ3軸の表を埋めます。半期ごとに見直す運用にしておくと、機能追加による権限の肥大化に気づけます。点検結果の維持運用はKuuのエージェントガバナンス支援（AI Ops）でも支援しています。
参考
- LLM06:2025 Excessive Agency - OWASP GenAI Security Project
- Configure permissions - Claude Code Docs
- Hooks reference - Claude Code Docs
まとめ
Excessive Agencyは、機能・権限・自律性のどれか1つでも過剰なら成立します。点検は、ツールの一覧化、権限の最小化、不可逆操作への承認という順で進めれば、専任者がいなくても回せます。まずは最も権限の広いエージェント1つから始めてください。棚卸しの進め方や運用設計のご相談は、Kuu株式会社までお問い合わせください。