AIエージェントは、答えるだけでなく動く。メールを読み、ファイルを開き、社内のシステムに書き込み、外部にデータを送る。便利になったぶん、攻撃されたときに失うものも大きくなった。
すでに実例がある。2025年6月には、Microsoft 365 Copilotの脆弱性「EchoLeak」（CVE-2025-32711、深刻度を示すCVSSは9.3）が公表された。メールなどに仕込まれた指示によって、Copilotが参照できる社内データが持ち出されうるというものだ。Microsoftは修正済みで、悪用された形跡は確認されていない。2026年7月には、Hugging Faceが、自律的に動くAIエージェントのシステムによって本番環境の一部に侵入されたと公表した。日本でも、IPAの「情報セキュリティ10大脅威 2026」で「AIの利用をめぐるサイバーリスク」が組織編の3位に初めて入っている。
ここでは、AIエージェントを業務に入れる企業が最初に決めるべきことを、権限と承認の設計を中心に整理する。下敷きにするのは、Webアプリの脆弱性対策で知られるOWASPが2026年8月4日に公開した「OWASP GenAI LLM Top 10 2026」だ。AIエージェントを業務のどこに入れるかはAIエージェント導入の実践ガイドに、現場に入ってAIを実装する職種についてはFDEとは？に書いた。
AIエージェントのセキュリティが、これまでと違う3つの点
チャット型のAIと比べて、エージェントでは守り方の前提が3つ変わる。
- 命令とデータの区別がない。エージェントは、利用者の指示も、読み込んだWebページも、ツールの実行結果も、同じ文章の流れとして読む。外部の文書に「この内容を外に送れ」と書いてあれば、それを指示として扱ってしまうことがある。これが間接的なプロンプトインジェクションだ。
- 被害の範囲がツールの届く範囲まで広がる。OWASPの2026年版は、エージェントでは被害がチャット画面から、エージェントのツールが届く範囲全体に広がると書いている。メール送信のツールがあればメールで、データベースへの書き込み権限があればデータベースで被害が起きる。
- 人の速さを前提にした監視が追いつかない。エージェントは人より速く、何回でも試す。人が気づいてから止める運用では間に合わない場面が出てくる。
社内でのAI利用全般のリスクは生成AIのセキュリティ対策ガイドで6つに整理した。エージェントでは、そのうちのプロンプトインジェクションと過剰な権限の2つが、とくに重くなる。人がAIに何を入力してよいかの社内ルールはAI利用規程の作り方で扱った。
プロンプトインジェクションは防ぎきれない前提で設計する
OWASPの2026年版は、10大リスクの1位にプロンプトインジェクションを置いたうえで、確実な防止策は今のところ存在しないと書いている。生成AIのモデルは命令とデータを構造として区別しないからだ。そのため守りは、入力を検査して止めることよりも、仕組みの設計で行うべきだとする。命令の境界はいずれ突破されると考え、突破されてもエージェントにできることと届く範囲を絞っておく、という考え方だ。
AIを作る側も同じ見方をしている。Anthropicは2025年11月、ブラウザを操作するAIへのプロンプトインジェクションについて、攻撃の成功率を1%まで下げたと発表した。そのうえで、1%は大きな改善だが、それでも意味のあるリスクが残ると書いている。
私の見方では、ここから導ける実務上の結論は1つだ。入力の検査やAI側の防御は、効けば被害が減る「減らす手段」として入れる。そのうえで、突破されたときに何が起きるかを権限で決めておく。検査を入れたから安全、とは考えない。
過去に起きた情報漏洩の事例と出口ごとの対策は生成AIの情報漏洩事例8選にまとめてある。
AIエージェントの権限設計：5つの原則
OWASPの2026年版は、2025年版でLLM06だった「過剰なエージェンシー」（Excessive Agency）をLLM03に上げた。原因は、機能が多すぎること、権限が強すぎること、自律性が高すぎることの3つだとしている。そこで示されている対策を、設計の原則として5つにまとめた。
| 原則 | 中身 | 例 |
|---|---|---|
| 1. ツールを絞る | 仕事に要らないツールは最初から渡さない | URLの内容を取りに行く必要がないなら、その機能を持たせない |
| 2. ツールの機能を絞る | 1つのツールの中でも、要る操作だけを実装する | メールを要約するツールは読み取りだけにし、送信や削除を入れない |
| 3. 権限を絞る | ツールが使うアカウントの権限を最小にする | 商品を薦めるエージェントは、商品の表の読み取りだけにする |
| 4. 利用者の権限で動かす | エージェントの権限ではなく、依頼した利用者の権限の範囲で操作する | 複数のエージェントをつなぐときも、最初の利用者の権限を引き継ぐ |
| 5. 許可の判断をAIに任せない | 操作してよいかは、AIではなくツールや下流のシステムが規則で判断する | 返金や送金の可否は、AIの出力ではなく業務システムの規則で決める |
5つ目がいちばん見落とされやすい。システムに「この操作は許可されていない場合は実行しないこと」と指示文で書いても、指示文はプロンプトインジェクションで上書きされうる。許可の判断は、AIの外にある普通のプログラムと権限の仕組みで行う。
AIとツールをつなぐ標準の1つであるModel Context Protocol（MCP）の仕様も、プロトコル自体はこうした安全の原則を強制できないと明記し、ツールを呼ぶ前に利用者の明示的な同意を得ることや、同意と認可の流れを実装する側で作ることを求めている。標準に乗れば安全になるわけではない。
操作の重さで承認を分ける
人の承認は強い守りだが、すべての操作に付けると、承認する人が中身を見ずに押すようになる。OWASPの2026年版も、影響が小さい操作や取り消せる操作は自動で通し、影響が大きい操作や取り消せない操作は人の確認に回す、段階的な考え方を示している。例として、店舗クレジットでの返金は取り消せるので自動処理、外部への支払いは取り消せないので人の承認、という分け方を挙げている。
私は、操作を4つに分けて承認を決めることを勧めている。
| 操作の種類 | 例 | 承認 |
|---|---|---|
| 読み取り | 社内文書の検索、表の参照 | 自動。ただし読める範囲は権限で絞る |
| 取り消せる書き込み | 下書きの作成、社内チケットの起票 | 自動。記録を残し、あとから戻せるようにする |
| 取り消せない操作 | 削除、確定処理、本番環境の変更 | 人の承認 |
| 外への送信、お金と権限 | メールの送信、外部へのデータ送信、支払い、権限の付与 | 人の承認。送り先や金額の上限も規則で決める |
Anthropicは、自社のコーディング用エージェントのClaude Codeについて、既定では読み取りだけの権限で動き、コードやシステムを変更する前には人の承認を求める設計だと説明している。読み取りは自由に、変更は確認してから、という分け方は、業務のエージェントでもそのまま使える。
導入前のチェックリスト
AIエージェントを本番に入れる前に、次の10項目を確かめる。1つでも答えられない項目があれば、そこが最初に手を入れる場所だ。
- エージェントが読む外部の情報（Webページ、メール、添付ファイル、他社のデータ）を一覧にしたか
- 渡しているツールと、ツールごとの機能を一覧にし、要らないものを外したか
- ツールが使うアカウントは専用で、権限は最小か
- 操作は依頼した利用者の権限の範囲で行われるか
- 許可の判断を、指示文ではなくプログラムと権限で行っているか
- 取り消せない操作と外への送信に、人の承認が付いているか
- 送り先、金額、件数に上限を設けているか
- エージェントが何を読み、何を実行したかの記録が残り、誰が見るか決まっているか
- 異常に気づいたとき、エージェントを止める手順と担当が決まっているか
- 本番に入れる前に、悪意のある文書を読ませる試験をしたか
どれも新しい技術ではなく、これまでのシステムで当たり前にやってきた最小権限と承認の考え方を、AIエージェントに当てはめ直したものだ。違うのは、AIが自分で判断して動くぶん、その考え方を省いたときの被害が大きいことだと私は考えている。社内のAIの使われ方と権限の設定を外から確かめたい場合は、私たちのAI利用セキュリティ診断で扱っている。