powered by TechFeed
表示モード
Deep Dive

AIエージェントのシステムプロンプトはセキュリティ対策にならない — AWS・SANSが示す「モデルを信頼しない」実装ガイド

9月3日、Help Net Securityが「Your AI agent's system prompt is not a security control」と題した記事を公開した。この記事では、AIエージェントのシステムプロンプトをセキュリティ制御として頼ることの危険性と、AWS・SANSの専門家が示す実装レベルの対策について詳しく紹介されている。

9月3日、Help Net Securityが「Your AI agent's system prompt is not a security control」と題した記事を公開した。この記事では、AIエージェントのシステムプロンプトをセキュリティ制御として頼ることの危険性と、AWS・SANSの専門家が示す実装レベルの対策について詳しく紹介されている。


システムプロンプトはアクセス制御ではない

AIエージェントのシステムプロンプトに「このユーザーが閲覧権限を持つデータだけを見せるように」と書いても、それはセキュリティ制御にならない。ユーザーが巧みに誘導すれば、エージェントはその制約を超えてデータを返す。プロンプトは「バイパスされ、無視され、上書きされ得る」——これがAWSでSecurity Hub・GuardDuty・Inspectorを統括するGee Rittenhouse氏と、SANSフェローのEric Johnson氏が共同ガイダンスで明言していることだ。

対策の正しい場所は、モデルのコンテキストウィンドウに届く前の層にある。クエリをユーザーの権限にスコープし、既存のRBAC(ロールベースアクセス制御)またはABAC(属性ベースアクセス制御)の仕組みの中でデータを絞り込む。「ある操作を通常のアプリUIでできないユーザーなら、そのユーザーの代わりに動くエージェントも同様にできないべきだ」というのが、両氏の基本原則だ。

この原則は当然に見えるが、現実は厳しい。McKinseyの調査によれば、AI導入率が80%に達する一方で、AIガバナンスの実装率は10%にとどまる。IBMの「Cost of a Data Breach Report 2025」では、管理されていないシャドーAIが多い組織は、そうでない組織と比較して1件の侵害あたり平均67万ドル(約1億円)多くコストがかかることが示されている。


「3つの能力を1つのエージェントに持たせるな」

リスクが集中する典型的な構成がある。センシティブデータへのアクセス・外部通信能力・信頼できないコンテンツへの露出、この3つを1つのエージェントが同時に持つケースだ。

この組み合わせがなぜ危険かというと、信頼できないコンテンツはプロンプトインジェクションの侵入口になるからだ。一見普通の入力に見える場所に隠された命令が紛れ込み、エージェントが外部へデータを送り出す経路が完成する。OWASPはプロンプトインジェクションをAIアプリケーションへの最大の脅威として位置づけており、ツールや自律性を持つ前の最初期の段階からすでに危険にさらされる。3つのうち1つでも切り離せば、リスクの大部分は消える。


モデルは制御手段にならない

ガイダンスが繰り返し強調するのが、「モデルは決してコントロールではない」という原則だ。実装レベルでは以下を意味する。

  • 出力段階でPIIを検出・マスクするコンテンツフィルタ
  • エージェントの認証情報ではアクセスできないイミュータブルバックアップ(変更・削除が不可能な形式で保持されるバックアップ)
  • ツール呼び出しごとに、アクセス対象と失敗時の影響を評価するポリシーエンジン

特に重視されているのが「ツール呼び出し層でのデフォルト拒否(default-deny)」だ。著者らはこれを「エージェントセキュリティにおける最も重要なアーキテクチャパターン」と呼ぶ。実装手段としてCedarOpen Policy Agentが名指しされている。

運用ルールはシンプルだ。影響が大きいアクションは信頼スコアに関係なく人間のチェックポイントを経由させる。影響が小さく信頼度が高いアクションだけを自動実行する。

何か問題が起きた場合の封じ込めは4層同時に発動する:認証情報の無効化とセッション停止・外部通信のブロック・ツールアクセスの無効化と状態の凍結・データ制限とログの強化。サーキットブレーカーは閾値違反を検知すると、人間の確認を待たずにエージェントを停止させる。エージェントは警告を見て立ち止まるような存在ではないからだ、と著者らは説明する。


ベースライン構築には30日かかる

エージェントの異常検知は、人間ユーザーを前提に作られた既存の分析モデルではそのまま使えない。トラフィックパターン、APIコール順序、リソースアクセスの周期性は、エージェント専用のモデルが必要だ。たとえばAIコーディングツールが発生させるマルチプロセス活動は、正常に動いている既存の検知システムからは異常に見える。

推奨手順は、最もリスクの高いエージェントから計測を始め、少なくとも30日分のベースラインデータを収集してから検知ルールをチューニングする、というものだ。そのデータを収集している間も、そのエージェントは本番で動き続けている点には留意が必要だ。


攻撃対象時間(Attack Surface Minutes)という指標

ガイダンスが導入する指標が「Attack Surface Minutes(攻撃対象時間)」——脆弱性が制御されるまでの間、悪用可能な状態にある時間だ。これはセキュリティ業界の「滞留時間(dwell time)」の概念を応用したものだ。

この数値がアーキテクチャ上の判断を決める。定期スキャンを継続的監視に切り替えるべき時期、バッチアラートをストリーミング検知に変える時期、手動トリアージを自動封じ込めに移行する時期——これらすべての基準になる。エージェントはミリ秒単位で動く。指標の単位が「分」であること自体、封じ込め側が追いつくべき差の大きさを示している。


詳細はYour AI agent's system prompt is not a security controlを参照していただきたい。