AIエージェントにシステムプロンプトで「ユーザーが閲覧を許可されている範囲だけを見せる」よう指示しておいても、誰かがそれを言いくるめた瞬間に、そのエージェントはより多くの情報を渡してしまいます。AWSでSecurity Hub、GuardDuty、Inspectorを統括するGee Rittenhouse氏と、SANS InstituteのフェローであるEric Johnson氏は、対策をもう一段階下に据えるべきだと提言しています。つまり、企業がすでに運用しているロールベースまたは属性ベースのアクセス制御システムの中で、取得時点でクエリをユーザーの権限範囲に絞り込み、結果がモデルのコンテキストウィンドウに届く前にフィルタリングするというアプローチです。
進展の4段階（出典:SANS）
両氏は、プロンプトは「回避されたり、無視されたり、上書きされたりし得る」と記しています。ある人物が通常のアプリケーションのインターフェースを通じて記録を取得できないのであれば、その人物に代わって動くエージェントもまた、それを取得できてはならないというわけです。
このガイダンスは、両氏に加えてAWSのセキュリティ専門家3名が共同で執筆したもので、すでにエージェントを稼働させている企業や、開発を積極的に進めている企業を対象としています。エージェントはユーザーに代わって認証を行い、複数のツール呼び出しを連鎖させ、承認を待つことなく複数ステップの作業を完了させます。そのため、たった一つの誤った指示が、リクエストを処理するわずかな時間のうちに本番データにまで到達してしまう可能性があります。
McKinseyの調査によると、AIを導入している組織は80%に上る一方、AIガバナンスを整備している組織はわずか10%にとどまっています。IBMの2025年侵害調査では、統制の効いていないシャドーAIのレベルが高い組織は、侵害1件あたり平均で67万ドル多く負担していることが判明しています。
一つのエージェントに持たせてはいけない3つの機能
単一のエージェントが、機密データへのアクセス権、外部と通信する能力、そして信頼できないコンテンツへの露出という3つを同時に備えていると、リスクは一気に集中します。
この3つが重なり合うと、エージェントはデータが外部へ流出する経路そのものになってしまいます。というのも、プロンプトインジェクションが仕込まれるのは、まさに信頼できないコンテンツの中だからです。一見ごく普通の入力に見えるものの中に、隠された指示が埋め込まれているのです。OWASPはプロンプトインジェクションをAIアプリケーションに対する最大の脅威と位置づけており、これはエージェントがツールも自律性も何も持たない、最も単純な導入段階からすでに牙をむきます。3つの要素のうちどれか一つでも単一のコンポーネントに集中させないようにすれば、リスクの大部分は取り除けます。
注視すべき「時間」という指標
アタックサーフェスの「分」という単位は、脆弱性が制御によって封じ込められるまでにどれだけの時間、悪用可能な状態が続くかを測るものです。これは滞留時間(dwell time)という考え方を借用しつつ、侵入者ではなく露出している時間の窓そのものに焦点を当てています。この数値がアーキテクチャ上の判断を左右します。定期的なスキャンを継続的な監視に切り替えるべきタイミング、バッチ処理のアラートをストリーミング検知に切り替えるべきタイミング、手動でのトリアージを自動封じ込めに切り替えるべきタイミングです。エージェントはミリ秒単位で行動します。それに対してこの指標の単位は「分」であり、著者ら自身もそう認めている以上、封じ込め側がどれだけ遅れを取り戻さなければならないかが見えてきます。
ベースライン構築には30日かかる
人間のユーザーを想定して構築された分析手法は、そのままエージェントには通用しません。トラフィックパターン、API呼び出しの順序、リソースアクセスの頻度には、それぞれ専用に設計されたモデルが必要です。AIコーディングツールが引き起こすマルチプロセスの活動は、正常に機能している既存の検知システムから見ると、異常なものとして映ってしまいます。
ここで示されている指針は、最もリスクの高いエージェントから優先的に監視対象とし、検知ルールを調整する前に少なくとも30日分のベースラインデータを収集するというものです。チームは1か月分のデータが揃った段階でルールを調整しますが、その収集期間中もまさに稼働し続けているのは、最もリスクの高いエージェントに他なりません。
制御はどこに置くべきか
著者らは「モデル自体は決して制御にはならない」と記しています。実務上これが意味するのは、出力される個人情報(PII)を検知・削除するコンテンツフィルタ、エージェントの認証情報ではアクセスできないストレージに保管する改ざん不可能なバックアップ、そして個々のツール呼び出しについて、それが何に触れるのか、失敗した場合に何が起こるのかを評価するポリシーエンジンです。著者らは、ツール呼び出し層でのデフォルト拒否(default-deny)こそが、エージェント型セキュリティにおいて最も重要なアーキテクチャパターンだと位置づけており、これを大規模に運用する手段としてCedarとOpen Policy Agentを挙げています。影響度の大きいアクションは、信頼スコアがどうであろうと人間によるチェックポイントへと回されます。一方、信頼度が高く影響度の小さいアクションは、無人のまま実行されます。
いざ何か問題が起きた際には、封じ込めは4つの層で同時に発動します。認証情報の失効とセッションの停止、送信トラフィックの遮断、ツールアクセスの無効化と状態の凍結、そしてデータの制限とログ記録の強化です。サーキットブレーカーは、閾値違反が起きた時点で人間の確認を待たずにエージェントを停止させます。これは、警告を示されたエージェントが、人間のように立ち止まって考え直すことはない、という考えに基づいています。すべてのプロンプト、ツール呼び出し、応答は改ざん不可能なストレージに記録され、後から意思決定の連鎖を再構築できるようになっています。
ツール呼び出し層でのデフォルト拒否は、他の対策が破られたときにも持ちこたえる要となる部分です。モデルが誤った振る舞いをしているときも、プロンプトが汚染されているときも、行動のベースラインがまだ構築途中であるときも、この仕組みは機能し続けます。フレームワークの他の部分は、このチェックが働くまでの時間を稼いでいるにすぎません。
翻訳元: https://www.helpnetsecurity.com/2026/09/03/sans-aws-agentic-ai-security/
