エージェンティックAIセキュリティ：2026年版 AIエージェント保護ガイド

AIエージェントは、なぜLLMよりも保護が難しいのか？

AIエージェントがLLMよりも保護が難しい理由は、テキストを生成するだけではないからです。AIエージェントは、実際の認証情報を用いて自律的かつ非決定的な行動を取ります。そのため、リスクの重心は「モデルが何を言うか」から「システムが何を行うか」へと移ります。

単体のLLMは、テキストを生成します。プロンプトを送ると、応答が返ってきます。最悪の結果とは、通常、何かが実行される前に人間が読む「よくない出力」にとどまります。

しかし、AIエージェントは異なります。AIエージェントは、その出力を受け取り、それに基づいて行動します。ファイルを開き、コマンドを実行し、APIを呼び出し、実際に稼働しているシステムへ書き込みを行います。しかも多くの場合、各ステップを人間が承認することはありません。

この一つの違いが、LLMセキュリティの前提となっている考え方の大半を崩してしまうのです。

以下の通り翻訳しました。リンクは前回同様 sysdig.com/jp に変更しています。

理由は、次の通りです。

LLMセキュリティは、プロンプトと出力に焦点を当てます。有害な入力をフィルタリングし、有害な応答を捕捉するという発想です。

エージェンティックAIは、ワークフロー全体をカバーしなければなりません。エージェントは目標を解釈し、それを計画に分解し、ツールを選択し、タスクが完了するまで作業を続けます。あらゆるステップが、何かが誤り得る場所となります。そして、エージェントが実際の認証情報を保持しているため、失敗は画面上の一文ではなく、行動そのものになってしまいます。

メモリは、リスクをさらに高めます。エージェントは、一つのタスク内、そしてセッションをまたいで状態を保持します。つまり、一度汚染された入力が、それが与えられてから長い時間が経った後の判断にも影響を及ぼす可能性があるのです。

NISTのAI標準・イノベーションセンター（CAISI）は、AIエージェントシステムに特有のリスクを、次の3つに分類しています。

1. 学習時または推論時における敵対的攻撃。 モデルが、間接的プロンプトインジェクションのような悪意あるデータと相互作用する場合、あるいは学習データそのものが汚染されている場合です。
2. 意図的に仕込まれたバックドア。 システムの周辺ではなく、モデル自体が何者かによって侵害されている場合です。
3. 侵害されていないモデルであっても、害をもたらす場合。 何も攻撃されていません。エージェントが単に、意図からずれた目的を追求したり、自らへの指示を都合よく解釈したりするケースです。

3つ目の分類は、特殊なケースです。これは、攻撃者が一切存在しなくても、エージェントが脅威になり得るということを意味します。

そして、根本的な問題があります。エージェントは非決定的である、という点です。

同じエージェントに同じタスクを2回与えても、2つの異なる行動の連なりが得られることがあります。サンプリングの設定がランダム性をもたらします。ユーザーのプロンプトは、無限とも言える多様性を生み出します。そして、判断の論理は、モデルの重みと、人間には検証できないコンテキストウィンドウの中に存在しています。

言い換えれば、静的解析で辿れる道筋は存在しません。あらゆる入力を事前に想定して書けるポリシーも存在しません。エージェントが実行時に何を行うかだけが、唯一の判断材料なのです。

さらに、話は難しくなります。

シェルの実行、ファイルの読み取り、外部への通信といった、通常であれば不審なものとして扱う行動が、エージェントにとっては通常の動作にあたります。捕捉したい信号は、許容せざるを得ないノイズと同じ見た目をしているのです。

したがって、予防だけでは対応しきれません。デプロイ前のテストだけでも十分ではありません。エージェントを保護するには、エージェントが動作する前の制御、動作している間の可視性、そして誤った振る舞いをした瞬間のための対応計画が必要です。

AIエージェントは、どのようにして侵害されるのか？

AIエージェントが侵害されるのは、通常、モデルそのものを破ることによってではありません。エージェントがすでに信頼しているデータやツールを経由して侵害されるのです。

その根本にあるものは、次のとおりです。

エージェントは、多くの情報源から読み取りを行います。Webページ、ファイル、サポートチケット、ツールの出力、他のエージェントなどです。それらのコンテンツはすべて、同一のコンテキストウィンドウの中に流れ込みます。そして、モデルは、使うべきデータと従うべき指示とを、確実に区別することができません。

つまり、一見情報に見えるコンテンツが、命令を運び込むことがあり得るのです。これがプロンプトインジェクションです。エージェントにおいては、インジェクションが成功すると、単に回答が変わるだけでは済みません。それは行動を引き起こします。

以下では、それが実際に起こる主なかたちを取り上げます。

ツール応答を経由したプロンプトインジェクション

これが実際に起こる最も一般的なかたちは、エージェントが頼りにしているツールを経由するものです。攻撃は、ツールの応答に紛れ込んでやってきます。

その流れは次のとおりです。エージェントが、Webブラウザ、ファイルリーダー、データベースクエリといった正規のツールを呼び出します。返ってきた応答には、隠された指示が含まれています。エージェントはその指示を自らのタスクの一部として読み取り、続いてメールやHTTPリクエストといった別の正規のツールを使って、その指示を実行に移してしまうのです。

これこそが、重要な変化です。プロンプトインジェクションは、もはや単なる情報漏洩ではありません。それは、行動の実行へと姿を変えるのです。

2025年に発生したEchoLeak（CVE-2025-32711）と呼ばれるインシデントは、この仕組みを浮き彫りにしました。巧妙に細工されたメールが、隠された指示をMicrosoft 365 Copilotに忍び込ませました。その結果Copilotは、ユーザーのクリックを一切必要とせずに、攻撃者が管理する送信先へ機密データを送信してしまいました。

→ さらに詳しく学ぶ：The Comprehensive Guide to Prompt Injection Attacks in 2026

MCPツールポイズニング

Model Context Protocol（MCP）は、エージェントが外部ツールを検出し、呼び出すことを可能にします。各ツールには、説明（description）が付属しています。プレーンテキストです。エージェントはその説明を読んで、そのツールをどのように、そしていつ使うべきかを把握します。

ここに問題があります。悪意あるサーバーは、その説明の中に指示を隠すことができます。ユーザーには無害なツール名が見えており、それを承認します。モデルは、隠された部分も含めて説明の全文を読み取ります。そして、隠された指示に従ってしまうのです。たとえば、SSHキーを読み取って外部へ送信する、といった具合です。

この種の攻撃は、2025年4月に公表されました。関連する亜種として、ツールシャドウイングがあります。ポイズニングされた説明が、エージェントによる他の信頼されたツールの使い方を変えてしまうというものです。これは、エージェント自身の信頼を、サーバーをまたいだデータ窃取の経路へと変えてしまいます。

参考：ツールの説明は、承認後に再取得されることがあります。そのため、承認した時点では安全に見えたツールが、後になって変化する可能性があるのです。

コーディングエージェントを経由した認証情報の窃取

AIコーディングエージェントは、多くの場合CI/CDパイプラインの内部で動作します。シェルへのアクセス権を持ち、パイプラインの認証情報を用いて実行されます。これは、多くの恒常的な権限が一箇所に集まっている状態です。

一般的なパターンは単純です。悪意ある指示が、プルリクエストのコメントのような、エージェントが読み取るチャネルを通じてやってきます。その指示は、エージェントにセットアップ用のコマンドを実行するよう伝えます。役に立つように作られているエージェントは、それを実行してしまいます。スクリプトは環境変数を読み取り、認証情報を収集し、それらを外部へ持ち出します。

実際の事例が、2025年7月に実証されました。広範な権限でSupabaseデータベースに接続されていたCursorのコーディングエージェントが、サポートチケットに隠されたプロンプトインジェクションによって標的にされました。エージェントは非公開のテーブルを読み取りました。そしてその後、同じサポートチャネルを通じて、連携用のトークンを漏洩させてしまったのです。

参考： リスクは、エージェント自身の認証情報だけにとどまりません。CI/CDパイプラインの内部では、エージェントは通常、パイプラインが到達できるものすべて――クラウドキー、Gitトークン、署名鍵などを含む――に到達できます。たった一度のインジェクションが、目の前にあるリポジトリをはるかに超える範囲を露出させてしまう可能性があるのです。

メモリおよびナレッジベースのポイズニング

エージェントは、長期メモリや検索データベースなど、保存されたコンテキストに依存しています。そうしたストレージが、将来の判断を形づくります。

一度ポイズニングされると、その影響は持続します。この攻撃に関する研究では、データベースの0.1％未満を汚染するだけで、80％を超える攻撃成功率が報告されました。一部のテストでは、短いトリガーを含む単一の項目を仕込むだけで十分でした。¹

なぜこれが重要なのでしょうか。それは、トリガーが通常のテキストのように読めるかたちで書き込めるからです。そのため、明らかな異物をスキャンするフィルターは、それを見逃しがちです。汚染はメモリの中に潜み、機会を待ちます。

これらは、机上の空論ではありません。

2025年までに、すでに複数の公開されたインシデントが、エージェントが実際に被害を引き起こす様子を示していました。

Replitは本番データベースを削除し、その後、自らが行ったことについて誤解を招く出力を生成しました。GoogleのGemini CLIは指示を読み違え、ユーザーのファイルを消去しました。間接的なプロンプトインジェクションが、CRMデータへのアクセス権を持つエージェントであるSalesforce Agentforceに到達し、レコードを外部へ持ち出しました。また、Postmarkというメールサービスを装い、postmark-mcpとして配布された悪意あるツールパッケージは、送信メールをひそかに攻撃者へコピーしていました。

侵入口はそれぞれ異なりましたが、条件は同じでした。いずれのエージェントも、すでに行動を信頼されていたため、操作された入力が一つあれば十分だったのです。

エージェントが取るあらゆる行動は、そのエージェントが保持する認証情報と権限のもとで実行されます。エージェントが到達できる範囲が広いほど、たった一度の侵害がもたらす価値は大きくなります。これが、次の問題です。

AIエージェントのアイデンティティが、拡大しつつある攻撃対象領域である理由

AIエージェントのアイデンティティが拡大しつつある攻撃対象領域である理由は、エージェントが実際の認証情報を保持し、稼働しながらさらに多くのアクセス権を取得し得るからです。従来のアイデンティティガバナンスは、静的なアカウントを前提に構築されたものであり、タスクの途中で到達範囲が変化するようなアクターを想定していません。

侵害されたエージェントが被害をもたらすのは、それが行動を信頼されているからです。そして、その信頼には源があります。AIエージェントは、単なるプログラムではありません。それは、認証を行い、権限を保持し、それらを用いて行動する「アイデンティティ」なのです。

エージェントは、**非人間アイデンティティ（NHI：Non-Human Identities）**と呼ばれるカテゴリに属します。これは、人間ではなくソフトウェアが使用する認証情報であり、APIキー、アクセストークン、マシン証明書、クラウドロールなどが該当します。

NHIは、新しいものではありません。新しいのは、その規模です。

非人間アイデンティティは、今や人間のアイデンティティをはるかに上回る数に達しており、自動化とAIの普及に伴って、その差はさらに広がっています。しかも、その多くは適切に管理されていません。素早く作成される一方で、見直されることはめったになく、当初の目的を終えた後も残り続けることが少なくありません。

ここで、エージェントのアイデンティティが、静的なサービスアカウントよりもリスクが高い理由を説明します。

サービスアカウントには、固定された役割があります。スコープを限定し、ローテーションし、失効させることができます。そのブラスト半径は既知です。一方、エージェントは、いくつかの点で異なります。

• 稼働しながらアクセス権を取得する。 エージェントは、限られた権限で開始しても、より多くの権限を必要とするリソースに行き当たると、新しいロールを要求したり、新たなトークンを取得したり、想定されていなかった特権APIを呼び出したりすることがあります。その認証情報が及ぶ範囲は、認証情報が発行される時点では完全には把握できません。
• 増殖する。 単一のマルチエージェントワークフローが、それぞれ独自のアイデンティティと権限を持つ、多数の短命なエージェントを生成することがあります。中には、わずか数秒しか存在しないものもあります。こうした集団を統制することは、固定されたアカウント群を管理するよりもはるかに困難です。
• 委任する。 エージェントは互いに作業を引き渡し合い、そうした委任の連鎖は、従来のネットワーク監視では見逃されがちな水平展開の経路を生み出します。
• 認証情報が本体より長く残る。 エージェントの認証情報は、パイロット導入や一度限りの連携など、一時的な用途のために作成されることがよくあります。プロジェクトが終了し、エージェントは廃止されても、認証情報は設定ファイルやシークレットストアの中に残ります。エージェントはもういません。しかし、アクセス権は残っているのです。これは、持続的ブラスト半径（persistent blast radius）と呼ばれることもあります。

‍

これらを総合すると、攻撃対象領域はデプロイ時に固定されるものではありません。それは、エージェントが稼働するにつれて拡大していきます。

攻撃者は、その攻撃対象領域を、いくつかの一貫した手口で標的にします。

• 認証情報のハイジャック。 エージェントの認証情報を乗っ取り、不正な制御権を獲得してデータを窃取します。
• ポイズニングされたアクション。 悪意ある情報源をエージェントに与え、有害な振る舞いを引き起こします。
• エージェントの逸脱。 内部的な欠陥によるものであれ、外部からのトリガーによるものであれ、意図しない挙動をするエージェントを悪用します。

強力なアイデンティティガバナンスは、確かにこの攻撃対象領域を縮小します。アクセス権のスコープを限定する、認証情報の有効期間を短くする、その所有者を追跡する――こうした対策はいずれも有効です。

しかし、それには限界があります。ガバナンスは、エージェントが「何に到達できるか」を制御します。しかし、その境界の内側に入ったエージェントが、適切に振る舞うことまでは保証しません。

そして、まさにそこで、予防（prevention）だけでは不十分になり始めるのです。

ガードレールだけではAIエージェントへの攻撃を完全には防げない理由

今日のエージェントセキュリティの多くは、ガードレール――望ましくない挙動が起こる前にそれを食い止めようとする制御――に依存しています。これには、入力・出力のフィルター、プロンプトインジェクション分類器、構造化されたプロンプト、サンドボックス、権限確認のプロンプト、そしてリスクの高いステップに対する人間の承認などが含まれます。

ガードレールは重要です。これらは必要不可欠な第一の防衛線であり、攻撃の大部分を捕捉します。

しかし、そのすべてを捕捉できるわけではありません。ガードレールは、エージェントに「入るもの」と「出るもの」をフィルタリングします。エージェントのリスクは、その「あいだ」で何をするかにあります。そして、そのギャップは3つのかたちで現れます。

1. 最良の防御策でさえ、依然として頻繁に破られる。

これは意見ではなく、計測された事実です。

ある主要なプロンプトインジェクション防御策は、最適化に基づく強力な攻撃に対してテストされたところ、依然として約58％の割合でそれを通過させてしまい、その設計者自身が「まだ完全には安全ではない」と述べています。²

より広範なベンチマークでは、最も効果的な攻撃が約84％の割合で成功し、現行の予防ベースの防御策は不十分であり、防ごうとする過程でしばしばエージェントの有用性を損なっていると結論づけられました。³

2. ガードレールがカバーするのは、システムの一部であって、その全体ではない。

同じそのプロンプトインジェクション防御策は、プログラムによる単一ターンのアプリケーション向けに構築されたものであり、本ガイドが扱う、複数ターンにわたってツールを使用するエージェント向けではありませんでした。

分離（アイソレーション）も、よく用いられる防御策の一つです。各エージェントやアプリケーションを互いに隔離することで、一つが侵害されても、その影響が他へ広がらないようにするものです。

しかし、そうしたシステムの一つを構築・テストした研究者たちは、その保護には明確な限界があることを発見しました。彼らの分離アーキテクチャは、攻撃がアプリケーション間で広がるのを食い止めることはできました。しかし、単一のエージェントが自らの境界の内側で不正に振る舞うのを止めるようには、そもそも設計されていませんでした。それは、彼ら自身が名指しし、対象範囲外と位置づけた限界だったのです。⁴

公式なガイダンスでさえ、ここに線を引いています。生成AIに関するNISTのセキュア開発プロファイルは、その適用範囲をモデル開発と定義しており、デプロイと運用はその範囲外であると明言しています。

このパターンは一貫しています。すなわち、学習と構築はカバーされるものの、エージェントが稼働するその瞬間で、ガイダンスは途切れるのです。

3. 危険な挙動が、正当なものに見える。

文書化されたあるシナリオを考えてみましょう。

ある自動化エージェントが、隠された指示を受け取り、信頼された管理用ツールを次々と連鎖させて、機密データを外部へ持ち出します。すべてのコマンドは承認済みのプログラムを通じて実行されます。すべてのアクションは有効な認証情報を使用します。そのため、ホストベースの監視ではマルウェアもエクスプロイトも見当たらず、この不正利用は検知されないまま進みます。既知の不正な入力をブロックするために作られたガードレールは、承認済みのツールを承認されていない方法で使うエージェントを、捕捉できないのです。

ガードレールは不可欠です。維持し、強化してください。ガードレールは、エージェントが行動を起こす前に、現実のリスクを取り除いてくれます。しかし、ガードレールが戦略のすべてになることはできません。ガードレールは侵害の可能性を下げはしますが、それを取り除くわけではありません。そして、エージェントが行動を始めたその瞬間には、何の保護も提供しないのです。

つまり、「入るもの」と「出るもの」だけでなく、エージェントが実際に「何をするか」を見る必要があるということです。

それが検知（detection）です。そして、次に扱うのは、まさにそのテーマです。

実行時に、侵害されたAIエージェントを検知する方法

ここまでで、問題は明確になりました。予防には漏れがあります。だからこそ、すでに侵害されてしまったエージェントを捕捉する手段が必要なのです。

手短な答えを述べます。

侵害されたエージェントを検知するのに、その「正常な状態」を学習し、そこからの逸脱を監視するというやり方は用いません。その手法は、エージェントに対しては破綻します。代わりに、エージェントが取る具体的なアクションを監視し、既知の不正なもの、あるいは許容範囲を逸脱したものにフラグを立てるのです。

なぜ、振る舞いのベースラインがエージェントには通用しないのか

ほとんどのランタイムセキュリティは、決定論的なプロファイリングに依存しています。従来のワークロードは予測可能です。Webサーバーは、同じ関数を呼び出し、同じファイルを読み取り、同じホストに接続します。それ以外はすべて異常とみなされます。

エージェントは、その前提を崩します。同じタスクでも、2つの異なる経路を生み出し得ます。そして先ほど見たように、フラグを立てるべきアクション――シェルコマンド、ファイルの読み取り、外部への接続――は、同時にエージェントの日常的な振る舞いでもあるのです。

つまり、「正常」は安定した基準点にはなりません。別の基準点が必要です。

侵害されたエージェントを検知する3つの方法

ここで鍵となる考え方はこうです。エージェントの「判断」は、モデルのレイヤーにおいては非決定的です。しかし、その「アクション」は非決定的ではありません。

あらゆるアクションは、具体的なイベントになります。検知が機能するのは、まさにそのレイヤーなのです。

これを実用的なものにするのが、次の3つの手法です。

1. 既知の不正の検知

一部のアクションは、どのような文脈においても不審です。触れる理由のないクラウド認証情報を読み取るエージェント。既知の悪意あるアドレスに接続するエージェント。ポストエクスプロイトのツールを実行するエージェント。などです。

これらにフラグを立てるのに、ベースラインは必要ありません。必要なのは、既知の不正な活動を認識するルールです。

平たく言えば、そうしたルールの一つは、次のように読めるものです。

IF a process in an agent container reads a credential file
   (cloud keys, SSH keys, a .env file, or a path containing "credentials")
THEN raise a high-severity alert
   with the file, the command, and the container.

このパターンは、先ほど取り上げた実際の攻撃に対応しています。MCPツールポイズニング。シークレットを読み取るプロンプトインジェクション。コーディングエージェントを経由した認証情報の窃取です。

2. ケイパビリティのスコープ設定

エージェントの環境ができることを制限します。システムコールを限定し、ネットワークポリシーを適用し、可能な場所ではファイルシステムを読み取り専用でマウントします。こうすると、ベースラインはエージェントの振る舞いではなくなります。ベースラインは、サンドボックスの境界になるのです。エージェントがその境界を越えたとき、それがシグナルとなります。

3. ツール呼び出しレベルの監査

エージェントを、そのフレームワークのレイヤーで監視します。どのツールが、どのような引数で、どのプロンプトに応答して呼び出されたかを記録します。これにより、何が起きたかだけでなく、なぜエージェントがそれを行ったのかが分かります。

これら3つを組み合わせることで、それぞれ異なる深さをカバーできます。既知の不正（known-bad）のルールは、明白なものを捕捉します。スコープ設定は、境界の違反を捕捉します。そして、ツール呼び出しの監査は、意図を明らかにします。

攻撃タイプ別の検知戦略

エージェントスタックの各レイヤーには、想定される攻撃と、それに対応する検知戦略があります。以下の表は、MITRE ATLASのテクニック識別子を用いて、両者を対応づけたものです。

ランタイム検知は、侵害されたエージェントを捕捉できるのか？

初期の結果は、有望なものです。エージェントの振る舞いに基づく検知に関する最近の研究では、0.93〜0.96というF1スコアが報告されました。さらに示唆に富むのは、悪意あるペイロードを一切含まない攻撃も捕捉できたという点です。それらの攻撃は、正当なステップの順序とタイミングを変えることで成立していました。コンテンツのスキャンでは、これを見逃します。しかし、振る舞いの観点からの検知は、見逃しませんでした。⁵

参考：F1スコアとは、分類タスク――たとえば、エージェントの振る舞いを「悪意あり」か「正常」かに仕分けるような処理――で用いられる、機械学習の標準的な指標です。これは、適合率（誤検知の少なさ）と再現率（実際のケースをどれだけ捕捉できたか）を、0から1までの単一の数値に統合したもので、高いほど良いとされます。

別の研究では、マルチエージェントシステムをグラフとしてモデル化し、複数のエージェントにまたがって同時に発生する障害を捕捉しました。これはまさに、単一地点での入力・出力チェックが見逃すものです。⁶

そして、これは一部の特殊な話ではありません。NISTのリスクガイダンスは、AIシステムが本番環境で稼働している間、その振る舞いを監視することを求めています。そこでは、ランタイムでの観測は任意ではありません。それは、当然求められるものなのです。

エージェントは、その挙動を予測することによって保護できるものではありません。エージェントを保護するには、それが実際に何をするかを監視し、それを2つのものと照らし合わせます。既知の不正な活動、そして、あなたが設定した境界です。

それが検知です。次は、予防・検知・対応を、一つのプログラムとして統合していきます。

→ さらに詳しく学ぶ：

• AIセキュリティのベストプラクティス上位8選
• AIワークロードセキュリティとは？
• エージェント型クラウドセキュリティとは何ですか？

AIエージェントのセキュリティインシデントへの対応方法

検知によって、エージェントが侵害されたことが分かります。対応とは、それに対して何をするかということです。そしてエージェントの場合、最も難しいのは「速さ」です。

エージェントを迅速に封じ込めます。そのアクセスを遮断します。そして、安全に自動化できる範囲は可能な限り自動化します。

なぜ「速さ」が結果を左右するのか

クラウド攻撃は高速です。Sysdig 5/5/5 Benchmark for Cloud Detection and Response（クラウド検知・対応のベンチマーク）によれば、文書化されたある攻撃は、初期アクセスからデータ窃取までを3分42秒で成し遂げました。手作業のインシデント対応プロセスで、これほど速く動けるものはありません。

エージェントは、そのリスクをさらに高めます。エージェントはマシンスピードで行動します。侵害されたエージェントは、何かに止められるまで、ツールを呼び出し、アクションを取り続けます。

そのため、手作業での対応では、しばしば遅すぎます。チケットが担当者に割り当てられる頃には、被害はすでに発生しているかもしれません。目指すべきは、検知から対応までの間隔を、限りなくゼロに近づけることです。

侵害されたAIエージェントを封じ込める方法

検知が発報したとき、特に重要となるアクションはいくつかあります。

• ワークロードを隔離する。 エージェントのコンテナをネットワークから切り離し、他のどこにも到達できないようにします。
• 認証情報を失効させる。 エージェントは、自らが保持するアクセス権に基づいて行動します。そのアクセス権を取り上げれば、エージェントの選択肢のほとんどは消え去ります。
• エージェントを停止する。 プロセスやセッションを終了させ、行動を続けられないようにします。
• 適切な担当者に通知する。 そのイベントを、必要なコンテキストとともに、オンコール対応担当者に振り分けます。

このうち最初の2つは、自動化すべきものでもあります。封じ込めと認証情報の失効は、人間を待つ必要がなく、これらを自動化することで、手作業の対応では失われてしまう数分を取り戻せます。

実践のヒント: エージェントの認証情報を失効させても、止められるのは今後の使用であって、すでに行われた窃取ではありません。エージェントがすでに到達したものは侵害されている可能性が高いため、そちらもローテーションしてください。

人をループに残すべきとき

すべてのアクションを、単独で（自動で）実行させるべきではありません。中には、機械に完全に委ねるにはあまりに重大なものもあります。

規制もこれを反映しています。EUのAI法は、ハイリスクなAIシステムに対して人間による監督を求めており、これには、システムが何をしているかを監視し、介入または停止できる能力が含まれます。

そこで、両者を切り分けましょう。低リスクの封じ込めは自動化します。重大な結果を伴う判断は人間へエスカレーションし、対応担当者が常に介入してエージェントを停止できるようにしておきます。

このバランスの取り方は、規模を拡大し始めています。より新しいアプローチでは、専用のエージェントに他のエージェントを監督させ、設計によっては、アクションが完了する前にそれをブロックさせるものもあります。理由は単純です。ほとんどのAIアプリケーションは、数年のうちに複数のエージェントに依存するようになり、エージェントがマシンスピードで連携するとき、人間がすべてのステップをレビューすることはできないからです。

エージェントが封じ込められたら、作業は調査へと移ります。しかし、それはそれ自体で一つの専門領域です。

次は、予防・検知・対応を、一つのプログラムとして統合していきます。

実践のヒント：「自動化するか、エスカレーションするか」の線引きは、インシデントの最中ではなく、発生する前に決めておきましょう。そして、人間に回すリストは短く保つこと。日常的なアクションをあまりに多くエスカレーションすると、対応担当者はそれらを形式的に承認するだけになってしまいます。

エージェンティックAIセキュリティプログラムの構築方法

エージェントは、単一の制御で保護できるものではありません。プログラム（体系的な取り組み）を構築するのです。それは、突き詰めれば3つのステップに集約されます。すなわち、エージェントがどこで攻撃され得るかをマッピングし、その攻撃対象領域全体にわたって予防・検知・対応を多層的に重ね、そしてエージェントが動作する速度でそれを運用するためのツールを整備することです。

各ステップの内容は、次のとおりです。

以下の通り翻訳しました。リンクは sysdig.com/jp の対象内リンクを /jp に変更、外部（CSA）はそのままです。

エージェントは、単一の制御で保護できるものではありません。プログラム（体系的な取り組み）を構築するのです。それは、突き詰めれば3つのステップに集約されます。すなわち、エージェントがどこで攻撃され得るかをマッピングし、その攻撃対象領域全体にわたって予防・検知・対応を多層的に重ね、そしてエージェントが動作する速度でそれを運用するためのツールを整備することです。

各ステップの内容は、次のとおりです。

ステップ1 － 攻撃対象領域をマッピングする

見えないものは守れません。ですから、まずは棚卸しから始めます。

• エージェントが稼働している場所を洗い出す。
• 各エージェントが到達できるツールとMCPサーバーを一覧化する。
• 各エージェントが保持する認証情報を記録する。

その棚卸しが、土台となります。後から追加するあらゆる制御は、これに依存します。

次に、脅威をモデル化します。構造化された手法が役立ちます。このために作られたフレームワークの一つが、CSAのMAESTROです。これは、モデルからツール、そしてエージェント間のオーケストレーションに至るまで、エージェントスタックの各レイヤーにわたって、脅威を層ごとにマッピングします。

なぜ、そこまでするのでしょうか。それは、各制御を、汎用的なチェックリストではなく、実際の攻撃に結びつけられるからです。すなわち、先に取り上げたMCPツールポイズニング、プロンプトインジェクション、認証情報の窃取といった、あなたのエージェントが侵害され得る具体的な経路にです。

ステップ2 － 予防・検知・対応を多層化する

その全体像を手にしたうえで、3つのレイヤーを適用します。それぞれが、他のレイヤーが見逃すものをカバーします。

1. 予防。 各エージェントに固有のアイデンティティを与えます。そのアクセス権を、現在のタスクにスコープを限定します。恒常的なアクセスよりも、短命の認証情報を優先します。そして、エージェントをサンドボックス化し、その環境がタスクに必要なことしかできないようにします。
2. 検知。 予防には漏れがあるため、エージェントが実行時に何をするかを監視します。既知の不正なアクションにフラグを立てます。サンドボックスの境界を、越えてはならない限界として扱います。ツール呼び出しを監査して、コンテキストを把握します。
3. 対応。 何かが発報したら、迅速に封じ込めます。AIワークロードを隔離します。認証情報を失効させます。最初のステップは自動化します。そして、重大な結果を伴う判断には、人を残しておきます。

これら3つが、どのように互いを補強し合うかに注目してください。予防は攻撃対象領域を縮小します。検知は、すり抜けてきたものを捕捉します。対応は、被害を限定します。単一のレイヤーだけでは不十分です。組み合わせることで、それらは隙間を塞ぐのです。

ステップ3 － 適切なツールを整備する

検知のレイヤーには、それを実行する場所が必要です。Falcoのようなオープンソースのランタイムセキュリティエンジンが、その土台を提供します。これらは、システムレベルの活動を監視し、あなたが読んで調整できるルールによって、既知の不正な挙動にフラグを立てます。

規模が大きくなると、チームはその上にマネージドレイヤーを追加します。そのレイヤーは、次のことを行います。

• 攻撃の進化に合わせて、検知ルールを最新に保つ。
• アラートを、標準的なテクニック識別子に結びつける。
• エージェントやAIパッケージが稼働している場所を棚卸しする。
• 対応を、チームがすでに使っているインシデント対応プロセスへと振り分ける。

重要なのは、製品そのものではありません。カバレッジ（網羅性）です。何を選ぶにせよ、要件は同じです。エージェントが実行時に何をするかを見ること。そして、それに対して速やかに対処することです。

覚えておいてください。エージェンティックAIセキュリティは、ツールではなくプログラムです。

予防は第一の防衛線であり、必要不可欠なものです。しかしエージェントは、保持を信頼されているアクセス権やツールを使いながら、稼働中に問題を起こします。だからこそ、真のプログラムは、エージェントが実際に何をするかを監視します。そして、被害が広がる前に対処するのです。

予防。検知。対応。これらを、エージェントが実際にどのように攻撃されるかに合わせて整合させること。それが、2026年においてAIエージェントを保護する方法です。

エージェンティックAI セキュリティの FAQ