AIエージェントのセキュリティを徹底解説！10のリスクと企業の対策も紹介

議事録の作成や経費精算の下処理をAIエージェントに任せる部門が現れ、情報システム部門には「このツールを使ってよいか」の相談が届き始めています。一方で、AIが読み込んだメールの指示に従って利用者のメールを削除した例が提供元の安全性テストで公表されており、承認する側は判断材料がそろわないまま相談だけを抱えることになります。

判断が難しいのは、AIエージェントのセキュリティが「AIに何を入力するか」だけでは決まらないためです。この記事では、AIエージェントのセキュリティで何が新しいのか・特有のリスク10項目・公表された実例・企業がとるべき対策と承認前の確認点を、公的機関と提供元の一次情報に基づいて解説します。

記事を読めば、任せてよい業務の範囲と条件を自社の言葉で決められるようになります。危険の大きさを決めるのはAIの賢さではなく、与える権限・操作前の承認・行動の記録の3つの設計です。

AIエージェントのセキュリティは何が新しいのか

AIエージェントの安全性を考える前に、対象が何であり、なぜ従来の対策だけでは足りないのかを確かめておく必要があります。押さえておきたい前提は、以下の3つです。

• AIエージェントは目標に向かって自律的に行動するAIシステム
• 被害が「誤った答え」ではなく「誤った行動」として業務に届く
• 公的機関と国際団体が2026年に新しい脅威として整理した

AIエージェントは目標に向かって自律的に行動するAIシステム

総務省と経済産業省の「AI事業者ガイドライン」第1.2版(2026年3月31日公表)は、AIエージェントを「特定の目標を達成するために、環境を感知し自律的に行動するAIシステム」と定義しています。質問に答えて終わるのではなく、メールを読んで返信案を送る・社内文書を検索して報告書をまとめる・Webで調べて発注するといった行動まで自分で進める点が特徴です。

製品名で線を引かないことが大切です。チャット型のAIでも、メール・カレンダー・社内システムとの連携機能を有効にすれば、読んだ内容に応じて操作を実行するエージェントと同じ性質を持ちます。「エージェントと名乗る製品だけを管理する」発想では、連携機能を有効にしたチャットAIが対象から漏れます。

被害が「誤った答え」ではなく「誤った行動」として業務に届く

行動するAIでは、だまされたときや誤動作したときの結果が「間違った回答」ではなく「間違った操作」になります。誤った送信・データの削除・不要な購入といった結果が、人が確認する前に業務へ直接届く点が新しさです。

IBMの解説記事は、AIエージェントの脅威の特徴として、攻撃対象領域の拡大・高速な自律的アクション・予測不可能な推論・透明性の欠如の4点を挙げています。連携先が増えるほど攻撃の入口が増え、人の承認を待たずに次々と操作が進む点が前の2つです。同じ入力でも出力が完全には予測できず、判断の過程を後から追いにくい点が後の2つにあたります。

従来の生成AI対策が不要になるわけではありません。機密情報を入力しない・学習設定を確認するといった対策は引き続き必要で、そこに「実行」に伴う権限・承認・記録の対策が加わると捉えるのが正確です。

公的機関と国際団体が2026年に新しい脅威として整理した

IPA(情報処理推進機構)が2026年1月29日に公表した「情報セキュリティ10大脅威2026」では、組織向けの3位に「AIの利用をめぐるサイバーリスク」が初めて選出されました。ランサム攻撃とサプライチェーン攻撃に次ぐ順位で、AIの業務利用が専門家約250名の審議で主要な脅威に位置付けられた形です。IPA「情報セキュリティ10大脅威2026」

国際的なセキュリティ団体OWASPは2025年12月9日に「OWASP Top 10 for Agentic Applications 2026」を公開し、100名を超える専門家の査読を経てエージェント特有のリスクを10項目に整理しました。AI事業者ガイドライン第1.2版にAIエージェントの定義が入ったことと合わせ、AIエージェントは「様子見の新技術」ではなく管理対象として扱われる段階にあります。OWASP Top 10 for Agentic Applications 2026

AIエージェントに特有のセキュリティリスク10項目【OWASP 2026】

OWASPの10項目は開発者向けの分類ですが、導入を判断する立場でも「何が起こりうるか」を数え上げる地図として使えます。AIエージェント特有のリスク10項目は、以下のとおりです。

• 目標の乗っ取り(Agent Goal Hijack)
• ツールの誤用と悪用(Tool Misuse and Exploitation)
• IDと権限の乱用(Identity and Privilege Abuse)
• 部品の供給網の汚染(Agentic Supply Chain Vulnerabilities)
• 想定外のコード実行(Unexpected Code Execution)
• 記憶と文脈の汚染(Memory and Context Poisoning)
• エージェント間通信の不備(Insecure Inter-Agent Communication)
• 障害の連鎖(Cascading Failures)
• 人とエージェントの信頼の悪用(Human-Agent Trust Exploitation)
• 逸脱したエージェント(Rogue Agents)

目標の乗っ取り(Agent Goal Hijack)

読ませた文書やWebページ、ツールからの応答に紛れ込ませた指示で、エージェントの目標や行動の選び方をすり替えられるリスクです。OWASPは、エージェントと基盤のモデルが「指示」と「読ませた内容」を確実には区別できないことを原因に挙げています。

外部の情報に指示を仕込んでAIを操る手口がプロンプトインジェクションです。IPAの「AI利用者のためのセキュリティ豆知識」(2026年4月2日公開)も、Webページ内の不正な指示を利用者の指示と誤認して生成AIが情報漏洩や不正送金を実行する可能性を注意点に挙げています。エージェントが読む情報のうち、外部の誰かが書き換えられるものがどれだけあるかを洗い出すことが、対策の出発点です。IPA「AI利用者のためのセキュリティ豆知識」

ツールの誤用と悪用(Tool Misuse and Exploitation)

与えられた権限の範囲内であっても、エージェントが正当なツールを危険な形で使ってしまうリスクです。OWASPは例として、価値のあるデータの削除・有料APIの過剰な呼び出し・情報の持ち出しを挙げています。

原因は不正な指示だけではなく、あいまいな依頼や不適切な委任でも起こるため、対策は7項目のうち「操作の単位で承認と禁止を設定する」が該当します。

IDと権限の乱用(Identity and Privilege Abuse)

エージェントが引き継いだ認証情報や委任された権限を足がかりに、本来より広い範囲へアクセスされるリスクです。OWASPは、利用者中心のID管理とエージェントの設計との食い違いが原因で、エージェントに固有の管理されたIDがないと最小権限の徹底が不可能になると指摘しています。

社員の権限をそのまま持ったエージェントは、社員本人が見ていない場所でも社員として振る舞えます。エージェントのIDと権限を社員のアカウントと同じ仕組みで発行・失効させ、必要最小限に絞ることが対策です。

部品の供給網の汚染(Agentic Supply Chain Vulnerabilities)

エージェントが使うモデル・ツール・プラグイン・データ・他のエージェント・更新経路といった部品が、第三者の手で悪意あるものに差し替えられたり改ざんされたりするリスクです。OWASPは、エージェントが実行時に外部の部品を動的に読み込む構造のため、従来のソフトウェアより攻撃面が広がると説明しています。

便利な個人配布の拡張機能や接続部品を無審査で足す運用は、この型のリスクを直接広げます。接続を許可する部品を出所が確かなものに限る管理が対策の中心です。

想定外のコード実行(Unexpected Code Execution)

エージェントが生成したり受け取ったりしたプログラムが実行され、動作環境そのものを乗っ取られるリスクです。OWASPは、コードを生成して実行するエージェント一般に加えて、バイブコーディングのツールも対象に含めています。

対策は、エージェントの実行環境を業務システムや本番の認証情報から切り離すことです。実行環境が乗っ取られても、盗む価値のある認証情報がなければ被害は広がりません。

バイブコーディングのセキュリティを徹底解説！事故例と安全に使う条件も紹介

記憶と文脈の汚染(Memory and Context Poisoning)

エージェントが保持する会話履歴・記憶・検索対象の文書に、誤った情報や悪意ある指示を混ぜられ、以後の判断が偏るリスクです。OWASPは、汚染された記憶が目標の乗っ取りにつながることも多いと説明しています。

IPAの豆知識は、社内文書と外部由来のメールが同時に検索の対象になる状態を「混ぜるな危険」と表現しています。メールに仕込まれた不正な指示で社内情報が社外へ流出する可能性があるため、検索範囲を制限する運用上の選択肢を勧める内容です。読ませる情報の出所を分ける設計が、この型への現実的な対策です。

エージェント間通信の不備(Insecure Inter-Agent Communication)

複数のエージェントが連携する構成で、エージェント同士のやり取りに認証や改ざん防止がなく、メッセージの傍受・なりすまし・書き換えを許すリスクです。OWASPは、分散した構成では境界で守る従来の考え方が効きにくいと指摘しています。

業務の自動化が進むと受付・確認・承認を別々のエージェントに分ける構成も選択肢に入るため、連携を追加するときは通信の相手をどう確かめるかを提供元に確認してください。

障害の連鎖(Cascading Failures)

1つの誤り(誤った生成・悪意ある入力・壊れたツール・汚染された記憶)が、連携する他のエージェントやツールへ伝わり、全体の障害へ増幅するリスクです。OWASPは、エージェントが自律的に計画・保存・委任するため、1つの誤りが段階ごとの人の確認をすり抜けて保存された状態に残ることを問題にしています。

対策の考え方は「誤りの発生」ではなく「誤りの伝わり方」を止めることです。影響範囲を業務単位で区切り、全社のエージェントを一斉に止められる手段を用意しておくと、連鎖の途中で食い止められます。

人とエージェントの信頼の悪用(Human-Agent Trust Exploitation)

エージェントの流ちょうな説明や自信のある提案を人が信じすぎ、独立した確認なしに操作を承認してしまうリスクです。OWASPは、権威に見える説明で監督をすり抜けさせる手口を問題にしています。最終的な操作を人にやらせることで、記録上はエージェントの関与が見えなくなるためです。

承認を挟む設計は承認する人が中身を確かめて初めて機能するため、承認画面で「何を・どこへ・誰の権限で」を確認できる表示にすることと承認する人にリスクを伝えておくことが対策です。

逸脱したエージェント(Rogue Agents)

外部からの侵入や部品の改ざんをきっかけに、エージェントが本来の役割や許可された範囲から外れ、有害な行動や欺くような行動を続けるリスクです。OWASPは、個々の行動は正当に見えても全体として有害になる点を、従来のルール型の監視では封じ込めにくい隙間だと説明しています。

この型に対しては、行動の記録を人の操作と区別して残し、想定外の動きを検知したら止められる体制が対策になります。記録がなければ逸脱に気づくことすらできません。

AIエージェントのセキュリティ事故として公表された実例と共通点

危険は仮定の話ではありません。当事者の一次発表がある実例3件と、そこから読み取れる共通点を紹介します。

• Microsoft 365 Copilotの情報漏洩につながる欠陥(EchoLeak)
• Amazon Q拡張機能への不正なコードの混入
• Claude Codeを悪用したサイバー諜報活動
• 3件は別々の型で起きており対策も1つでは足りない

Microsoft 365 Copilotの情報漏洩につながる欠陥(EchoLeak)

2025年6月11日、MicrosoftはMicrosoft 365 CopilotにEchoLeakと呼ばれる欠陥(CVE-2025-32711)があったことを公表しました。米国の脆弱性データベース(NVD)の記載では、AIへの命令の混入(AI command injection)により、権限のない攻撃者がネットワーク越しに情報を取得できる欠陥です。

深刻度は、Microsoft自身の評価で9.3(Critical)、NVDの評価で7.5とされました。評価の内訳では、攻撃に利用者の操作も権限も必要ないと判定されています。Microsoftは、公表時点で完全に緩和済みで利用者側の対応は不要と説明しており、公表前の情報公開や実際の悪用は確認されていません。実害の報告はなく「AIに読ませる情報の経路そのものが攻撃口になる」ことを示した実証例として位置付けるのが正確です。NVD CVE-2025-32711

Amazon Q拡張機能への不正なコードの混入

2025年7月23日、AWSはコード支援AI「Amazon Q Developer」のVisual Studio Code向け拡張機能(バージョン1.84.0)に、悪意あるコードが混入して配布されたと公表しました。開発設定に含まれていた権限の広すぎる認証トークンが使われ、攻撃者がリリースに自動で取り込まれるリポジトリへコードを書き込んだことが原因です。

AWSの検査では、混入したコードは構文エラーのため実行に失敗し、サービスや利用者の環境に変更は加えられませんでした。AWSは認証情報を失効させて修正版1.85.0を公開し、1.84.0を配布停止にしたうえで、既存の1.84.0は削除して更新するよう案内しています。実害はなかったものの、狙われたのが「AIそのもの」ではなく「AIに届く部品の流通経路」だった点が、部品の供給網の汚染の実例にあたります。AWSセキュリティ速報AWS-2025-015

Claude Codeを悪用したサイバー諜報活動

2025年11月13日にAnthropicは、国家の支援を受けた攻撃グループが同社のClaude Codeを操作して行ったサイバー諜報活動を検知し、遮断したと発表しました。攻撃者は約30の組織への侵入を試み、少数の組織で成功したとされています。標的は大手テクノロジー企業・金融機関・化学メーカー・政府機関でした。

Anthropicの説明では、攻撃作業の80〜90%をAIが実行し、人の介入は1件の攻撃あたり4〜6回の重要な判断に限られました。攻撃者は作業を無害に見える小さなタスクへ分割し、正規のセキュリティ企業の従業員だと偽ってAIの安全機能を回避しています。AIが認証情報を作り上げたり、公開情報を機密と誤って報告したりする場面もありました。守る側だけが手作業のままでは釣り合わない前提で対策を考える必要があります。Anthropic「Disrupting the first reported AI-orchestrated cyber espionage campaign」

3件は別々の型で起きており対策も1つでは足りない

3件は同じ構図の繰り返しではありません。3件の型は、読ませる情報の経路(EchoLeak)・部品の流通経路(Amazon Q)・攻撃側の自動化(諜報活動)と、それぞれ異なります。

読み取れる共通点は2つあります。1つは、事故の入口がAIの賢さの不足ではなく、経路・部品・権限といった周辺の設計にあることです。もう1つは、脆弱性の実証と実際の被害を分けて読む必要があることです。EchoLeakとAmazon Qは実害なしで修正された事例にあたり、諜報活動は実際に侵入が成功した事例にあたります。ニュースの見出しだけで「AIエージェントは危険」と決めるのではなく、どの型が自社の使い方に当てはまるかで判断してください。

企業がとるべきAIエージェントのセキュリティ対策7つ

Anthropicのセキュリティ責任者(Deputy CISO)が2026年7月17日に公開した経営層向けの指針は、エージェントを動かす環境が満たすべき要件を7つ挙げています。要件はどの提供元の製品にも当てはめられる形で書かれており、企業がとるべき対策7つは以下のとおりです。Anthropic「A CISO's guide to agentic AI」

• IDと権限は既存の仕組みで発行し失効させる
• 接続先の許可リストでデータの境界を決める
• 操作の単位で承認と禁止を設定する
• 実行環境を分離して認証情報を持たせない
• 外部への通信先を許可リストで絞る
• 行動の記録を人の操作と区別して監視基盤へ流す
• 全社で一斉に止めるスイッチを用意する

IDと権限は既存の仕組みで発行し失効させる

エージェントのIDは、社員のアカウントを発行・失効しているのと同じ仕組み(IDプロバイダ)で管理します。理由は、退職や異動でエージェントだけ権限が残る状態を作らないためです。

権限の考え方は「必要最小限」です。Anthropicの指針は、業務を完了できる最も狭い能力だけを与える原則を「最小エージェンシー」と呼び、読み取りだけで足りる業務に書き換えの権限を与えない設計を基本にしています。既存の部署やグループの単位で権限を切り分けると、管理の手間を増やさずに済みます。

接続先の許可リストでデータの境界を決める

エージェントが到達できるシステム(メール・ファイル共有・社内データベースなどの接続先)を、管理者が許可した一覧に限ります。Anthropicの指針によると、どの接続先を有効にするかの判断がそのまま「エージェントがどのデータに届くか」の判断です。

信頼できない外部情報を読む業務には、片方向の制限を組み合わせます。指針が挙げる例は、Web検索の結果を入力に使うメール用のエージェントには下書きの作成だけを許し、人の確認なしに外部へ自動送信させないことです。IPAの豆知識が勧める「AIブラウザは社内用と社外用を分ける」「検索範囲を制限する」も、同じ発想の運用上の対策になります。

操作の単位で承認と禁止を設定する

接続先の単位だけでなく「読む」「下書きを作る」「送る」「削除する」といった操作の単位で、許可・承認必須・禁止を分けます。Anthropicの指針は「本番のデータベースが消える」ことが最大の懸念なら、削除の操作をエージェントの世界から外すよう勧めています。道具にない操作をエージェントが試みることはない点が理由です。

取り返しのつかない操作には人の承認を挟みます。Anthropicは自社のブラウザ操作機能で、公開・購入・個人情報の共有のような高リスクの操作前に利用者へ確認する仕組みを標準にしています。主要な製品には承認や権限の設定が備わっているため、まず既定の安全設定を切らずに使うことが第一歩です。

Claude Codeの権限設定を徹底解説！自動承認を安全に使う方法も紹介

実行環境を分離して認証情報を持たせない

エージェントが動く環境は、本番システムの認証情報を持たない隔離された場所にします。Anthropicは「エージェントが動く環境には盗む価値のある認証情報を置かない」ことを一貫した原則としており、接続先への認証は環境の外側の仕組みが代行し、環境そのものには認証情報が入らない構成を採っています。

この分離があると、読ませた情報に仕込まれた指示でエージェントが乗っ取られても、盗み出せる鍵がありません。想定外のコード実行への備えとしても、実行環境の分離は要になります。

外部への通信先を許可リストで絞る

エージェントの実行環境から外へ出る通信は、環境側から変更できない仕組みを通し、許可した宛先だけに限ります。Anthropicの指針は、通信先の許可リストをプロンプトインジェクションに対する最も強い対策と位置付けています。

理由は単純です。読ませた内容でエージェントがだまされても、攻撃者はデータを外へ持ち出す必要があります。通信先が許可された宛先だけなら、攻撃者の用意した場所へ送る手段がありません。

行動の記録を人の操作と区別して監視基盤へ流す

エージェントの操作は、どのツールを・どの引数で・成功したか失敗したかまで記録し、既存の監視基盤(SIEM)へ流します。Anthropicの指針は、エージェントの操作と人の操作を区別できることと、提供元が記録を「見に行く画面」ではなく「流し込める形」で提供することを要件にしています。

記録は事故対応のためだけではありません。Anthropicの社内例では、すべての操作が監視基盤に届いていたため、想定外の動きが数週間ではなく数分で表面化する状態を作れています。記録の中に指示文そのものを含めるかどうかは、社内の保存期間やプライバシーの方針を先に決めてから設定してください。

全社で一斉に止めるスイッチを用意する

事故の兆候があったとき、全社のエージェントの接続を一斉に止められる手段を、必要になる前に用意します。Anthropicの指針は、全体停止の前に「特定の部署だけ止める」「特定の接続先の書き込みだけ止める」といった段階的な手段も含め、3層の止め方を事故対応計画に書いておくよう勧めています。

止める手段がない状態は、無断利用と同じ状態です。指針は、禁止だけで対応した結果として生まれる無断利用を「記録がゼロで停止スイッチもない」ものと表現しています。

AIエージェントの導入を承認する前に確認する4つの質問

対策の一覧を全部そろえてから導入するのは現実的ではありません。Anthropicの指針は、個々の利用案件を審査するときの問いを4つに絞っており、この4つは提供元や推進部門への質問リストとしてそのまま使えます。承認前に確認する質問は、以下の4つです。

• 信頼できない外部の情報を読み込むか
• 何を実行でき、誰の権限で動くか
• 誤動作したとき影響はどこまで広がるか
• エージェントの行動を記録し人の操作と区別できるか

信頼できない外部の情報を読み込むか

「信頼できない」とは、攻撃者が書いたり書き換えたりできるものを指します。社外からのメール・公開のWeb・第三者の文書・公開されたコードの置き場が典型です。

Anthropicの指針は、読み込む外部情報が「何もない」ならエージェント特有のリスクはほぼゼロに近く、速やかに進めてよいとしています。反対に、外部情報を読む案件では、読んだ情報が実行できる操作とどう組み合わさるかを次の質問で確かめます。

何を実行でき、誰の権限で動くか

読み取りだけか、書き込みや削除もできるかで、心配の種類が変わります。ツールの呼び出し・コードの実行・外部への通信は、それぞれ影響の幅を広げる要素です。

すべての操作は誰かのIDのもとで実行されるため「誰の権限で動くのか」も確認します。Anthropicの指針は、自分専用の単一目的のIDで動くエージェントと社員本人が操作して本人が責任を負う使い方を、管理しやすい両端と整理しています。社員の権限を委任されたエージェントが本人の見ていない場所で動く中間の形は、責任があいまいになりやすい形です。

誤動作したとき影響はどこまで広がるか

影響範囲は「範囲×深刻さ」で見積もります。1つのファイルに届くのか会社全体に届くのか、結果は些細な異常で済むのか本当の事故になるのかを言葉にすることが目的です。

Anthropicが社内で運用する事故対応用のエージェントは、この問いに「最悪でも既に閲覧が制限された通知用の場所に機密性の低い記録が数行投稿される程度」と答えられる設計にしています。読み取り専用の記録・通知の投稿・新規文書の下書きだけを許し、編集や削除や外部送信は与えていないためです。最悪の結果を一文で言えない案件は、言えるところまで権限を削ってから承認します。

エージェントの行動を記録し人の操作と区別できるか

確認するのは、エージェントの操作が人の操作と区別された形で既存の監視基盤に届くかどうかで、届かない案件は事故が起きても原因をたどれません。

4つの答えがそろったら、結論の出し方は「可否」ではなく「承認できる条件」です。Anthropicの既定は、少人数で有効にして記録を見ながら対象を広げる段階的な展開です。判断に迷う項目が残るうちは、迷う項目に触れない範囲(読み取り専用・社内データのみ)で試験導入するのが安全側の判断になります。

AIエージェントを安全に運用する体制づくり

対策と審査の枠組みがあっても、運用する組織側の準備がなければ形だけになります。体制づくりで先に手を付けたい取り組みは、以下の4つです。

• 社内で動いているAIエージェントを棚卸しする
• 低リスクの業務から始めて記録を見ながら広げる
• 事故が起きたときの停止と報告の手順を決めておく
• 従業員に公認の使い方と注意点を伝える

社内で動いているAIエージェントを棚卸しする

最初の一歩は、社内で既に使われているAIエージェントの一覧を作ることです。対象が見えなければ、どの対策も始まりません。

棚卸しでは、ツールの名前・用途・読ませているデータ・実行させている操作・誰の権限で動いているかを部門ごとにまとめます。Anthropicの指針によると、四半期ごとに見直す従来のリスク台帳では変化の速いエージェントの利用を管理しきれないため、審査の過程そのものを自動化する工夫が必要です。公式の経路が遅いから人は迂回する、との指摘も同じ指針にあり、棚卸しと並行して公認の経路を速くすることが無断利用の抑止につながります。

シャドーAIとは？リスクと対策を徹底解説！公認ルートの作り方も紹介

低リスクの業務から始めて記録を見ながら広げる

公式に許可する最初の業務は、外部情報を読まず読み取り中心で影響範囲を一文で言えるものに絞ります。

設計の前提には注意点があります。Anthropicの社内例では、モデルを新しい版に入れ替えただけで事故対応用のエージェントが人の到着前に自分で修正に動き、別のエージェントへ依頼を出す行動が初めて現れました。修正は人の確認を経る仕組みだったため統制の範囲内に収まりましたが、権限や操作の制限は「今のモデルにできること」ではなく、半年先の能力を見込んで決める必要があります。

事故が起きたときの停止と報告の手順を決めておく

止める手段と報告の流れは、事故の前に決めて周知することが前提です。IPAが公開する企業の実践例では、自社でも起こりうる脅威ごとに従業員がとるべき初動対応を証拠保全の観点から定め、社内ポータルなどで周知しています。AIエージェントの事故でも、記録を消さない・接続を止める・報告窓口へ連絡するといった初動を、従業員の目線で1枚にまとめておくことが有効です。

従業員に公認の使い方と注意点を伝える

技術的な統制と並行して、従業員にはどこまでが公認の使い方かを具体的に伝えることが必要です。Anthropicの指針は、自社の環境で「信頼できない情報」に当たるものを文章にして決めておくよう勧めており、この一線があると以後の判断が楽になります。

伝える内容は、IPAの豆知識が挙げる利用者向けの注意点が土台になります。具体的には、営業秘密をクラウドのAIに教えないこと・AIブラウザを社内用と社外用で分けること・検索対象に外部由来のデータを混ぜないことの3点で、いずれも利用者本人の行動で減らせるリスクです。基礎となる生成AI全般の対策は、次の記事にまとめています。

生成AIのセキュリティを徹底解説！リスクの分類と会社でやるべき対策も紹介

AIエージェントのセキュリティに関するよくある質問

導入判断の場で残りやすい疑問に、3つ回答します。

• 対策すればAIエージェントは100%安全になりますか
• 従業員が個人契約のAIエージェントを業務に使ってもよいですか
• ベンダーには何を確認すればよいですか

対策すればAIエージェントは100%安全になりますか

なりません。Anthropicは2026年7月の指針で、モデルの性能向上とともにプロンプトインジェクションへの耐性は上がり攻撃の成功率は下がり続けているものの、ゼロではないと明言しています。

数字で示した公表もあります。Anthropicが2025年8月に自社のブラウザ操作機能を公開したときの社内テストでは、29種類の攻撃シナリオに基づく123件の試験で、対策なしの攻撃成功率23.6%が対策後に11.2%へ下がりました。当時の試験値であり現在の安全性を表す数字ではありませんが、提供元自身が「下げられるがゼロにはならない」と示している点が重要です。攻撃を前提に権限を絞り、危険な操作に承認を挟んで記録を残す多層の設計が要る理由はここにあります。

従業員が個人契約のAIエージェントを業務に使ってもよいですか

会社の記録と停止の手段が及ばないため、業務データを扱う用途では認めない判断が安全側です。

禁止で終わらせず、読み取り専用・社内データのみの低リスク用途から公認の経路を用意し、そこへ誘導する方が無断利用の抑止まで含めて効果があります。

ベンダーには何を確認すればよいですか

企業がとるべき対策7つを、そのまま質問に置き換えます。加えてAnthropicの指針は、IDプロバイダやSIEMの提供元も含めて「今の自社環境で動いている状態を見せてほしい」と求めるよう勧めています。資料上の対応可否ではなく、実際に動く様子で確認することが判断の質を上げる近道です。

AIエージェントのセキュリティは権限・承認・記録の設計で管理できる

AIエージェントのセキュリティで新しいのは、だまされたときの結果が「誤った答え」ではなく「誤った行動」として業務に届く点です。OWASPが整理した10のリスクは、目標の乗っ取り・権限の乱用・部品の汚染・記憶の汚染・障害の連鎖など、いずれも「読ませる情報」「与える権限」「つながる部品」の設計に根があります。公表された実例も、AIの賢さの不足ではなく周辺の設計の隙で起きたものです。

企業がとるべき対策は、次の7つに集約されます。

• IDと権限は既存の仕組みで発行し失効させる
• 接続先の許可リストでデータの境界を決める
• 操作の単位で承認と禁止を設定する
• 実行環境を分離して認証情報を持たせない
• 外部への通信先を許可リストで絞る
• 行動の記録を人の操作と区別して監視基盤へ流す
• 全社で一斉に止めるスイッチを用意する

導入を止める必要はありません。任せてよい範囲と条件を自社の言葉で決められることが、この記事から得られる利益です。まずは社内のAIエージェントの棚卸しと承認前の4つの質問から始め、読み取り専用の低リスクな業務で権限・承認・記録の型を作ってから、対象を広げていきましょう。