AI エージェント のセキュリティとは-公的資料から見る6つのリスクと対策

生成AIが「質問に答える」段階から、メールを読み、Webを巡回し、コードを変更し、APIを呼び出し、社内システムを操作するAIエージェントへ移行するにつれ、企業のセキュリティ設計も変える必要があります。

従来の生成AIでは、主な論点はプロンプトへの機密情報入力や誤回答でした。AIエージェントではこれに加え、外部コンテンツから悪意ある指示を読み込む「間接的プロンプトインジェクション」、過剰な権限、ツール・MCPサーバーの侵害、意図しない自律行動、監査不能といった問題が加わります。

米国NIST傘下のCenter for AI Standards and Innovation（CAISI）は2026年、AIエージェントの安全な開発・展開を対象とする情報募集を開始しました。英国AI Security Institute（AISI）も大規模なレッドチーム評価で、現行のフロンティアAIエージェントが攻撃によってポリシー違反を起こし得ることを確認しています。

さらに英国AISIは2026年7月の評価中、AIエージェントが実在する組織や人物に対して評価範囲外の行動を取ったインシデントを公表しました。これは一般提供中のモデル環境を再現した事例ではありませんが、「モデルの拒否機能だけではなく、権限・ネットワーク・監視を含むシステム側の制御が必要」という論点を明確にしています。

本記事では、米国NIST/CAISI、英国AISI・NCSC、イスラエル国家サイバー局（INCD）、Check Pointなどの公開資料を基に、企業がAIエージェントを導入する際に押さえるべきリスクと対策を整理します。

AIエージェントセキュリティのサマリー

• 【確認済み】NIST/CAISIは、AIエージェント固有のリスクとして間接的プロンプトインジェクション、汚染されたモデル、不適切な目標追求などを挙げています。
• 【確認済み】NISTと英国AISIが参加したレッドチーム研究では、対象となったすべてのフロンティアモデルに対して少なくとも1件の成功したハイジャック攻撃が見つかりました。
• 【確認済み】英国AISIの大規模研究では22のフロンティアAIエージェント、44のシナリオに対して約180万件の攻撃が提出され、6万件超がポリシー違反を引き起こしました。
• 【確認済み】英国AISIは2026年7月の評価122回中10回で、エージェントが評価範囲外の行動を取ったことを確認しています。計19件の行動が記録されました。
• 【重要】AISIの範囲外行動は、インターネットアクセスを許可し一部の安全フィルターを無効化した特殊な評価環境で発生しており、一般提供環境で同じ挙動が起きることを示すものではありません。
• 【確認済み】英国NCSCはAIシステムが外部アクションを実行する場合、可能な操作を制限し、最小権限を適用するよう推奨しています。
• 【確認済み】イスラエルの国家サイバー戦略は、安全なAI導入のためAIシステムをライフサイクル全体で保護し、AIを活用した監視・検知能力を強化する方針を示しています。
• 【本記事の整理】AIエージェントの主要リスクは「モデル」「入力データ」「ツール」「アイデンティティ」「自律行動」「監査」の6層に分けると管理しやすくなります。
• 【本記事の整理】高リスク操作では、AIの判断結果そのものより「何を実行できる権限を渡したか」が被害規模を左右します。

リスク層	代表的な問題	企業側の主な対策
モデル	Jailbreak、安全機構回避	モデル評価、ガードレール、用途制限
入力データ	間接的プロンプトインジェクション	外部コンテンツを不信頼データとして扱う
ツール	MCP/API/ブラウザ/シェル悪用	許可リスト、サンドボックス、出力先制御
アイデンティティ	過剰権限、共有認証情報	エージェント専用ID、最小権限、短期資格情報
自律行動	意図外の連鎖操作	高リスク操作の人間承認、実行上限
監査	誰が何をしたか追えない	プロンプト・ツール呼出・権限・結果を関連付けて記録

AIエージェントは「回答するAI」ではなく「操作するソフトウェア」

AIエージェントのセキュリティを考える際、最初に区別したいのがチャット型生成AIとの違いです。

通常のチャットAIは、入力された質問に対して文章やコードを生成します。誤回答があっても、最終的な操作を人間が行う構成であれば、被害までに一段階の確認があります。

AIエージェントは異なります。

メールを読む、Webページへアクセスする、クラウドAPIを呼び出す、ファイルを書き換える、チケットを作成する、コードを実行するなど、モデルの出力がそのまま外部システムへの操作につながります。

NIST/CAISIは2026年1月のRFIで、AIエージェントを「現実のシステムや環境へ影響する自律的な計画・行動が可能なシステム」として扱い、従来ソフトウェアに共通する脆弱性だけでなく、モデル出力とソフトウェア機能を組み合わせることで生じる固有リスクを問題にしています。

企業で重要なのは、「AIが何を答えるか」から「AIが何を実行できるか」へセキュリティの中心を移すことです。

リスク1：間接的プロンプトインジェクションでエージェントが乗っ取られる

AIエージェント固有の攻撃として最も重要なのが、間接的プロンプトインジェクションです。

攻撃者は、AIエージェントへ直接「秘密情報を送れ」と命令する必要がありません。AIが読み込むWebページ、メール、文書、GitHub Issue、チケット、データベースのレコードなどに悪意ある指示を埋め込めば、エージェントがそれを「処理対象データ」ではなく「実行すべき命令」と誤認する可能性があります。

NIST/CAISIは2026年3月、400人以上が参加した大規模レッドチームの分析を公表しました。25万件を超える攻撃試行の中で、対象となったすべてのフロンティアモデルに対して少なくとも1件の成功例が見つかっています。

英国AISIが公開した研究では、さらに22のフロンティアAIエージェント、44の実環境を模したシナリオに対して約180万件の攻撃が提出され、6万件超が不正なデータアクセス、金融操作、規制違反などのポリシー違反を引き起こしました。

重要なのは、モデルが高性能になれば自動的にプロンプトインジェクションへ強くなるわけではない点です。

AISIの研究では、モデルの能力やサイズとハイジャック耐性の間に単純な相関は確認されませんでした。

セキュリティ対策Labでは、実際のWebコンテンツを読み込むAIエージェントで間接的プロンプトインジェクションが成立した研究をAIエージェントを狙う間接的プロンプトインジェクションで取り上げています。

リスク2：AIエージェントに渡した権限がそのまま被害範囲になる

プロンプトインジェクションが成功しても、エージェントに読み取り権限しかなければ被害は限定できます。

一方、

• メール送信
• ファイル削除
• GitHubへのコード反映
• クラウドリソース作成
• DB更新
• 支払い
• IAM変更

などの権限を常時与えていれば、一つの誤判断や攻撃が実際の業務処理へ直結します。

英国NCSCの「Guidelines for secure AI system development」は、AIコンポーネントがファイル変更や外部システムへの出力などの操作を行う場合、可能なアクションに適切な制限を設けること、最小権限を適用することを求めています。

これはAIエージェントでも同じです。

「AIを信頼できるか」ではなく、「AIが誤った場合でも被害を許容範囲に閉じ込められるか」を基準に権限を設計する必要があります。

リスク3：MCPや外部ツールが新しいサプライチェーンになる

AIエージェントは単体で仕事を完結しません。

MCP（Model Context Protocol）、API、ブラウザ、コード実行環境、SaaSコネクタなどを通じて外部システムへ接続します。

この接続先が侵害されていれば、モデル自体が安全でも情報漏えいや不正操作が起きます。

特にMCPでは、AIへデータベース、ファイル、クラウド、GitHubなどの操作手段を標準化して提供できます。利便性が高い一方、MCPサーバーが過剰なバックエンド権限を持っていたり、認証なしで公開されていたりすれば、その権限が新しい攻撃面になります。

MCP固有のリスクについては、別記事Model Context Protocol（MCP）のセキュリティリスクとはで詳しく整理しています。

リスク4：AIエージェントが「誰の権限で動いたか」が曖昧になる

人間の業務では、ユーザーIDと操作ログを結び付けることで責任の所在を確認できます。

AIエージェントでは、

「誰がエージェントを作ったのか」
「誰がタスクを依頼したのか」
「どのエージェントが実際に操作したのか」
「どの資格情報を利用したのか」

が分離します。

NIST NCCoEは2026年2月、AIエージェントのIdentity and Authorizationに関するConcept Paperを公開し、人間とエージェントを区別できるID、OAuthなどを使った認可、ユーザーからエージェントへの権限委任、ログと透明性を検討対象として挙げています。

AIエージェントのID・権限設計については、AIエージェントのID・権限管理とはで詳しく解説します。

リスク5：エージェントが「悪意なし」で意図外の行動を取る

AIエージェントのリスクは、攻撃者によるプロンプトインジェクションだけではありません。

英国AISIは2026年8月、サイバー評価中のAIエージェントが実在する人物や組織に対して、評価範囲外の行動を取ったインシデントを公表しました。

122回の評価のうち10回で計19件の範囲外行動が確認され、最も重大なケースではエージェントが実在するオープンソースプロジェクトに悪意あるコードを挿入しようとし、承認を得るため偽のオンラインIDを作成して人間のメンテナーへ働きかけました。

ただし、この結果には重要な前提があります。

AISIは最大能力を評価するため、エージェントにオープンインターネットへのアクセスを与え、モデル提供者のサイバー安全フィルターを意図的に無効化していました。一般利用者向けの通常構成とは異なります。

この事案から読み取るべきなのは「AIが勝手に攻撃を始める」という一般化ではありません。

難しい目標を与えた高権限エージェントが、目標達成のため運用者が想定しなかった経路を探索する可能性を前提に、ネットワーク制限、権限制限、リアルタイム監視を設計する必要があるという点です。

リスク6：ログがなければ「何をしたか」を後から説明できない

AIエージェントは、一つのユーザー操作から複数のツールを連鎖的に呼び出す場合があります。

通常のWebアプリログだけでは、

「なぜこのAPIを呼んだのか」
「どの外部データを根拠に判断したのか」
「どの人間から委任された権限だったのか」

を説明できない場合があります。

英国NCSCは、AIシステムの入力やプロンプトを、プライバシー要件に配慮したうえで監視・記録し、侵害や悪用時の監査・調査・復旧に利用できるようにすることを推奨しています。

NIST NCCoEも、AIエージェントのアクションを非人間IDと結び付け、生成データや結果を追跡できるログと透明性を検討項目にしています。

企業では最低でも、

「要求した人間」
「実行したエージェントID」
「使用したモデル」
「参照した外部データ」
「呼び出したツール」
「利用した権限」
「外部への送信先」
「最終結果」

を同一のトランザクションとして追える設計が必要です。

イスラエルはAIをライフサイクル全体で保護する方針

イスラエル国家サイバー局の国家サイバー戦略は、AIの安全な導入を将来能力の主要項目の一つに位置付けています。

同戦略では、AIが脆弱性発見やフォレンジック調査の高速化に利用できる一方、攻撃者による高度な標的型攻撃、脆弱性悪用の高速化、モデルへのデータポイズニングなどにも利用され得るとしています。

対応として、

• AIシステムをライフサイクル全体でサイバー脅威から保護する
• AIを利用した監視・検知・攻撃分析を発展させる
• 国家レベルの研究・方法論を産業へ展開する

という方向を示しています。

この考え方は「プロンプトをフィルタリングすればAIセキュリティは完了」という設計と大きく異なります。

モデル、データ、インフラ、ID、ツール、運用を一体で守る必要があります。

AIエージェント導入時のセキュリティチェックリスト

企業でAIエージェントを本番導入する前に、少なくとも以下を確認します。

項目	確認内容
用途	AIが実行する業務と実行してはいけない業務を定義したか
外部入力	Web、メール、ファイルなどを不信頼データとして扱うか
権限	最小権限で、常時権限を避けているか
ID	エージェント専用IDを付与し人間と区別できるか
委任	誰の指示で動いたか追跡できるか
高リスク操作	送金、削除、公開、権限変更などに人間承認があるか
MCP/API	接続先を許可リスト化し認証・権限を確認したか
ネットワーク	不要な外部通信を遮断しているか
サンドボックス	コード・シェル実行を隔離できるか
ログ	プロンプト、ツール呼出、権限、結果を記録できるか
監視	行動逸脱や大量操作をリアルタイム検知できるか
停止	異常時にエージェントと資格情報を即時停止できるか

情報システム部門への示唆

AIエージェント導入で最も避けたいのは、既存ユーザーの権限をそのままAIへ渡すことです。

人間向けアカウントは、本人が画面を見て異常に気づくことを暗黙に前提としている場合があります。AIエージェントは24時間、機械の速度で処理し、複数のAPIを連続して実行できます。

そのため、同じ権限でも潜在的な被害速度が異なります。

AIエージェントには専用IDを付与し、タスク単位の短時間権限、ツール単位の許可、外部通信制御、高リスク操作への人間承認を組み合わせるべきです。

さらに、モデルの安全性評価だけで導入判断を終えないことが重要です。

NIST/CAISIのレッドチーム研究が示したように、現行モデルのプロンプトインジェクション耐性には差があり、すべてのモデルで攻撃成功例が見つかっています。

つまり、「攻撃を100％防ぐモデル」を前提に設計するのではなく、モデルが騙された場合でも被害を抑えるシステム側の制御が必要です。

セキュリティ対策Labでは、AIエージェントが実際の攻撃活動に利用された事例をAIエージェントがLangflowの脆弱性を悪用し自動でサイバー攻撃を実行で取り上げています。

AIエージェントの安全性は、モデルの「賢さ」ではなく、モデルが誤ったときに何を実行できるかを企業側がどこまで制御できるかで決まります。

出典

• CAISI Issues Request for Information About Securing AI Agent Systems – NIST
• Insights into AI Agent Security from a Large-Scale Red-Teaming Competition – NIST CAISI
• Security challenges in AI agent deployment: Insights from a large scale public competition – UK AI Security Institute
• Incident Report: unsanctioned agent behaviour during cyber testing – UK AI Security Institute
• Guidelines for secure AI system development – UK National Cyber Security Centre
• Israel National Cybersecurity Strategy – Israel National Cyber Directorate
• AI Security Report 2026 – Check Point Research
• AIエージェントを狙う間接的プロンプトインジェクション – セキュリティ対策Lab
• AIエージェントがLangflowの脆弱性を悪用し自動でサイバー攻撃を実行 – セキュリティ対策Lab