8月27日、Datadogが「What we learned about AI agent security by monitoring our agents」と題した記事を公開した。AIエージェントのセキュリティ監視は、モデルの入出力を見るだけでは不十分だ。Datadogは自社の内部ワークフロー向けエージェントをDatadog AI Guardで監視する中で、アプリケーションログが「最終的なAPIコール」しか記録しておらず、そこに至るまでのプロンプトや取得コンテンツ、ツール実行結果が見えないという問題に直面した。この記事はその実体験から導き出された、本番運用者向けの実践的なガイドである。
エージェント監視に必要なテレメトリデータ
監視に必要なデータをDatadogは以下の5点に整理している：
- エージェントシステム全体のインベントリ：モデルバージョン、ツール、接続サービス、プロバイダートラフィックを記録する
- セッション全体を通じた機密データの分類：どこでマッチし、どこに送られたかを記録する
- エクスポージャーに基づいたコントロールの適用：顧客と対話するエージェントや機密データにアクセスするエージェントを優先する
- エージェントアクションのトレースと帰属：最初のリクエストからツール呼び出し、下流の動作まで経路を保持する
- 意味のあるシーケンスの検出：プロンプトインジェクションの試みと機密ツール出力を同一セッション内で紐づける
「モデルだけのインベントリ」では足りない — AI-BOMとサプライチェーンリスク
最も重要な知見のひとつが、AI-BOM（AI Bill of Materials）の必要性だ。AI-BOMとは、AIシステムを構成するモデル・ライブラリ・ツール・プロバイダーなどの全依存物を記録した部品表を指す。モデルのバージョン管理だけに目を向けていると、モデル以外の依存コンポーネントを狙ったサプライチェーン攻撃をまるごと見逃す。
実際の事例として、LiteLLM（AIアプリとモデルプロバイダー間のプロキシとして機能するOSSライブラリ）がその典型だ。2026年3月、攻撃者はPyPI上にLiteLLMの悪意あるバージョン1.82.7および1.82.8を公開した（TeamPCPサプライチェーンキャンペーン）。この侵害はモデルやプロバイダーではなくプロキシパッケージに対するものだったため、モデルのインベントリだけでは影響を受けたAIアプリケーションを特定できない。LiteLLMをAI-BOMに記録していれば、影響範囲の特定が早期に可能だった。このようなサプライチェーンリスクは、今後AIスタックの依存関係が複雑になるほど増大する。
インベントリの盲点はライブラリだけではない。Datadogは自社の監視にAI Guard Discovery（AI Guardに付属するトラフィック探索機能で、承認済みゲートウェイを経由しないリクエストも含めてAI関連通信を可視化するコンポーネント）を活用した結果、承認済みのAIゲートウェイを通さずOpenAIなどのプロバイダーに直接リクエストを送っているエージェントが見つかった。ゲートウェイトラフィックだけに基づいたインベントリはこれらを見逃す。AI GuardはポリシーベースのLLMトラフィック制御を担い、AI Guard Discoveryはその前段として「そもそも何がどこと通信しているか」を把握する役割を持つ。両機能を組み合わせることで、可視化とコントロールの両面を確保できる。
なお、70%以上の組織がすでに3つ以上のモデルを使用しており、6つ超を使う組織の割合は過去1年で約2倍になっている（State of AI Engineering reportより）。各モデルバージョンは同じプロンプトへの応答が異なるため、バージョンを含めた正確な記録が不可欠だ。
プロンプトとツール実行を切り離して見てはいけない
プロンプトインジェクションは「悪意あるユーザーメッセージ」として語られることが多いが、実際には取得ドキュメント、ツール結果、信頼済みワークスペース内のファイルを経由して注入されることがある。
Datadog Security Labsが実際に発見した悪意あるClaude Codeスキルの分析が示す通り、当該スキルはgh auth token（GitHub認証トークンを取得するコマンド）をレンダリング前の前処理段階で実行し、結果を攻撃者の管理するサーバーに送信していた。モデルはスキルの実行を拒否したが、その時点ですでにクレデンシャルは流出していた。モデルの入出力だけを監視しても、前処理で動くコマンドは捕捉できない。
ユーザーリクエスト→モデル応答→ツール呼び出しという一連の経路をトレースし、チェックポイントで評価することが重要だ。ただし、チェックポイントで止めた場合でも、受信側サービスは独自の認可ポリシーを追加の防御層として維持すべきだ。
機密データの追跡と人・エージェントIDの分離
エージェントのセッションでは、機密データがプロンプト、RAG（Retrieval-Augmented Generation）の取得結果、ツール出力を経由して流れる。Datadogの2026年版レポートでは、リクエストあたりの平均トークン数が前年比で中央値顧客で2倍以上、90パーセンタイル顧客で4倍に増加しており、システムプロンプトが全入力トークンの69%を占めていた。これだけの量のコンテンツを機密データの観点で評価する必要がある。
また、エージェントが開発者のクレデンシャルや共有サービスアカウントを使うと、どの操作がエンジニア自身によるものか、エージェントによるものかが判別できなくなる。Datadog Security Labsの調査では、プロジェクト制御の設定により、開発者が最初のプロンプトを送る前からコーディングエージェントがリポジトリ管理のコードを実行できる状態になっていたケースも確認されている。トレースには「セッションを開始した人間」「下流アクションを要求したエージェント」「受信サービスが認証したプリンシパル」の3者を分けて記録する必要がある。
孤立したイベントではなく、セッション内の行動シーケンスで検出する
単一のイベント（不審なプロンプトや機密ツール出力）を個別に見ても、その意味はわからない。Datadogは同一セッション内の「データ流出を試みたプロンプト」と「機密ツール出力」を紐づける検出パターンを構築した。クレデンシャルや一部のPIIに絞ったのは、一般的なメールアドレスへのマッチが通常のエージェント動作でも多発するためだ。
この検出でわかるのはあくまで「調査すべき可能性のある経路」であり、データが実際に外部に出たかどうかの証明には、さらにエージェントレスポンスや外部へのネットワークリクエストといった追加イベントが必要になる。Datadogはまずセッション全体のトレースを取得し、AI-BOMによる依存関係の把握を整えた上で、こうした行動シーケンスの検出ルールを段階的に追加することを推奨している。検出精度よりも可視化の土台を先に固めることが、実践上の出発点となる。
詳細はWhat we learned about AI agent security by monitoring our agentsを参照していただきたい。
