Agentic SOCを守る：プロンプトインジェクション、ログ汚染、そして新しい内部脅威

セキュリティログの中で攻撃者が影響を与えられるフィールドは、そのまま攻撃者が「書き込める」フィールドでもある。ホスト名、ユーザー名、DNSクエリ、User-Agent文字列、プロセスのコマンドライン——これは新しい話ではない。だからこそセキュリティログは常に「証拠」として扱われ、「信頼できる入力」としては扱われてこなかった。

新しいのは、agentic SOCが今やまさにそのフィールドを読み込み、LLMのcontext windowに投入し、モデルにそれを推論させ——そしてますますその結論に基づいて行動させている、という点だ。「ログは証拠」から「ログはプロンプト」への、この一つのシフトこそ、ほとんどの「agentic SOCの構築ガイド」が素通りしてしまう部分である。私たち自身もAgentic AI in SOC Workflowsで、triage/investigation/responseのアーキテクチャを詳しく解説するガイドを書いた。本記事はその「構築した後」の話だ——ツール呼び出しの権限を与えたばかりのその存在を、自分自身に対して使うよう説得されないようにするには、どうすればよいのか。

なぜこれはチャットボットのセキュリティとは違うのか

顧客向けチャットボットへのプロンプトインジェクションは「気まずい」で済む。だが、封じ込め権限を持つエージェントへのプロンプトインジェクションは「インシデント」になる。

その違いは、自律性とアクションが組み合わさっている点にある。操作された生成AIコパイロットは誤った文章を生成するだけであり、それに基づいて行動するのは依然として人間だ。しかし操作されたagentic SOCは、実際のケースを閉じ、実際のアラートを抑制し、誤った対象に対して実際の封じ込めアクションをトリガーできてしまう。2026年の研究はこの点を率直に指摘している——agenticシステムにおけるプロンプトインジェクションは出力を変えるだけでなく、システムポリシーを回避し、信頼されたツールを悪用し、機密データを直接漏洩させ得る。SOCにおいて「信頼されたツールの悪用」とは、エージェントがSOARプラットフォームにIPをホワイトリスト登録させたり、実際の侵入を良性の誤検知として記録させたりすることを意味しかねない。

セキュリティテレメトリは、ほぼ他のどのagenticデプロイメントよりもこの問題を悪化させる。理由は構造的に一つだけだ——エージェントに供給されるデータそのものが、設計上、敵対的だからだ。 HTTPリクエストのURI、DNS名、メールヘッダー、ログイン試行に使われたユーザー名——これらはすべて、インフラがログを記録する前に攻撃者が選択できるフィールドである。そのデータがSIEMに到達する時点で、攻撃者はすでに何かを埋め込むチャンスを得ている。エージェントのcontext-assembly処理がその生のフィールドを、運用指示と同じcontext windowに取り込んでしまえば、プロンプトインジェクションが必要とする条件をまさに作り出してしまうことになる。

計画しておくべき3つの攻撃パターン

ログフィールドインジェクション。 悪意ある行為者が、データ値というよりは指示のように読めるホスト名、ユーザー名、コマンドライン引数を作り込む——例えば、現在のイベントを「良性」として再分類するよう読み手に促す偽装フィールドなどだ。そのフィールドがInvestigation Agentが推論に使うプロンプトに直接連結されると、モデルは「攻撃を記述するデータ」と「それをどう記述すべきかという指示」を確実に区別できない場合がある。

エージェント間の伝播。 Triage → Investigation → Responseというマルチエージェントのパイプライン——4月のガイドで説明した構成——では、Triage段階での一度の汚染された判定がそこにとどまらない。それはInvestigation Agentへの入力となり、Investigation Agentは自らの結論をResponse Agentへ渡す。連鎖の早い段階でのインジェクションの成功は、下流で誤ったアクションへとカスケードしうる。しかも各エージェントは前段の構造化された出力を信頼するため、インジェクションは原因となったログフィールドから何段階も離れた場所に現れることになり、インシデントレビュー時の追跡が非常に困難になる。

ツールと来歴の誤用。 エージェントが人間のアナリストと同じ権限でケースノートを書き、アラートを閉じ、対応アクションをトリガーできるにもかかわらず、その出力がエージェント生成であると明確にラベル付けされていない場合、最初の問題の上にもう一つの問題が積み重なる。たとえエージェントの判断が正当であっても、監査が困難になる——あるケースノートが人間の判断を反映しているのか、モデルの推論を反映しているのか、一目では判別できなくなるからだ。これは攻撃者が関与する前から存在するガバナンス上の欠陥である。

ガードレールを組み込む

以上はagentic SOCそのものへの反論ではない。エージェントのcontext境界を、実装の細部としてではなく、セキュリティコントロールとして扱うべきだという主張である。

指示とデータを構造的に分離する——単なる慣習としてではなく。 エージェントの役割と制約を定義するsystem promptは、生のログフィールドを「何をすべきか」としてモデルが読むのと同じテキストブロックに文字列連結して構築されるべきではない。信頼できないフィールドは明確に区切られたデータブロックに置き、モデルには「推論の対象」として渡すのであって、「推論の根拠」として渡してはならない。

context組み立て後ではなく、その前にサニタイズする。 プロンプトに到達する前に制御文字を除去し、フィールド長に上限を設け、異常に長い値を拒否または切り詰める——正当なホスト名が4,000文字になることはなく、モデルにとって有用であるために全文を保持する必要もない。

すべてのツールをデフォルトで読み取り専用にする。 Investigation Agentは、脅威インテリジェンスフィードへの照会、関連イベントの取得、資産インベントリの確認を、書き込み権限なしで行えるべきだ。ケースのクローズ、IPのブロック、ホストの隔離といった書き込み・実行系のツールは、明示的なポリシー層——4月のガイドで解説したRESPONSE_POLICYテーブルのような仕組み——の背後に置く。ただし今や、その信頼度しきい値は自動化の調整ノブであると同時にセキュリティ境界でもある。

構造化され制約された出力を強制する。 次のステップが埋め込まれた自由形式のテキストを返すエージェントは、verdict・信頼度スコア・reasoningフィールドという固定スキーマのみを返すよう制約されたエージェントよりも、攻撃者に大きな攻撃対象領域を与えてしまう。後者であれば、下流で何かが実行される前に決定論的な層が解析・検証できる。

すべての信頼度スコアだけでなく、すべての資産クラスを重視する。 重要な資産に対する状態変更アクションは、エージェントの確信度にかかわらず人間の確認を必須とすべきだ。重要ホストにおける高確信度の誤答は、不要にエスカレーションされた低確信度の正答よりも悪い結果である。

来歴を作成時点で不変にラベル付けする。 エージェントが生成するケースノート、判定、アクションはすべて、append-only(追記専用)の監査ログにおいてエージェント生成として明確にタグ付けされ、人間のアナリストが書いたものとは区別されるべきだ。アナリストはレビューやオーバーライドはできても、どの判断がどこから来たのかを消し去るような形で履歴を静かに書き換えることはできてはならない。

エージェントも他のすべてと同様に監視する。 エージェント自身のツール呼び出し、クエリパターン、アクション頻度もテレメトリである。エージェントが守っているのと同じSIEMにそれらを供給し、エージェント自身の行動の異常を検知する——「ケースクローズ」アクションの異常な急増や、通常のスコープ外の資産に触れるクエリは、それ自体が調査に値するシグナルだ。

本番投入前にパイプラインをレッドチーム演習にかける。 ステージング環境でログフィールドにテスト用ペイロードを注入する——指示のように見えるよう作り込んだホスト名やユーザー名——そしてパイプラインがそれを不活性なデータとして扱うことを確認する。これは一度実施するコストは安く、省略すると高くつく。

flowchart TD
    A["攻撃者が制御するフィールド\nホスト名 ユーザー名 URI UA文字列"] --> B["ログ取り込み\nWazuh / SIEM"]
    B --> C["サニタイズ境界\n制御文字除去 長さ制限"]
    C --> D["構造化データブロック\n明確に区切られ 指示ではない"]
    D --> E["エージェントの推論\n固定system prompt デフォルト読み取り専用"]
    E --> F["構造化された出力\nverdict 信頼度 reasoning"]
    F --> G{"ポリシーチェック\n資産重要度 信頼度しきい値"}
    G -->|"自動承認"| H["アクション実行\nエージェント生成として記録"]
    G -->|"エスカレーション"| I["人間のアナリストによるレビュー"]
    H --> J["不変の監査ログ"]
    I --> J

ガバナンス文書は任意の事務作業ではない

上記はすべて技術的コントロールである。その上に置かれるべき組織的レイヤーは、どのアラートクラスをエージェントが自律的に処理してよいか、どのクラスがアナリストのレビューを必要とするか、そして信頼度スコアにかかわらず常に上級責任者の承認を要するのはどのクラスかを、事前に定めた文書化されたポリシーだ。これはコンプライアンスの体裁を整えるためのものではない——「エージェントがミスをした」という無限定の責任問題を、文書化され弁明可能な意思決定の軌跡へと変えるものである。

日本の規制環境では、これはAPPI(個人情報保護法)が求める自動処理に対する説明責任と直接結びつく——エージェントがログ内の個人情報(ユーザー名、IPアドレス、個人に紐づくセッションなど)を処理する場合、組織は自動化された判断に対する統制と追跡可能性を示せなければならない。また、指定された重要インフラ事業者に関わる経済安全保障推進法の枠組みの下では、初期判断がAIエージェントによるものであったとしても、報告義務や事前審査対応の責任が消えるわけではない。さらにJ-SOXの観点では、重要な業務プロセスに対する内部統制として、エージェントが実行したアクションの監査証跡が完全であることそのものが統制評価の対象になり得る。NISCのガイドラインが示す考え方とも整合的だが、書き換え不能な監査ログとガバナンス文書は、規制当局からの説明要求に組織が自信を持って応じるための土台になる。

優先すべきこと

1. まずcontext-assemblyのコードを監査する。 機能を追加する前に、生のログフィールドがプロンプトに連結されているすべての箇所を見つけ、サニタイズ境界を追加する。
2. まだであれば構造化出力へ移行する。 自由形式のエージェントテキストは、本番投入できる出力形式の中で最もリスクが高い。
3. ツールアクセスを拡張する前にエスカレーションポリシーを文書化する。 信頼度しきい値は出発点であって終着点ではない——資産の重要度がそれを上回るべきだ。
4. エージェントを監視対象の存在として計装する。 単なる監視ツールとしてではなく。
5. インジェクションテストのスケジュールを組む。 ペネトレーションテストと同様に、一度きりではなく定期的に実施する。

よくある質問

これはagentic SOCの導入がリスクが高すぎるという意味か。
いいえ——エージェントのcontext境界には、セキュリティスタック内の他のあらゆる信頼境界と同じ工学的規律が必要だという意味だ。Wazuh、Shuffle、DFIR-IRISをすでに運用している組織は、agenticな能力を放棄する必要はない。インシデント後に後付けするのではなく、最初からこれらのコントロールを組み込む必要がある。

これはLLMチャットボットのセキュリティ対策と同じものか。
関連はしているが、賭け金がより高い。チャットボットの最悪のケースは誤った出力だ。しかしSOCにおいてツール呼び出し権限を持つエージェントは実際のアクションを起こせる——ガードレールは、テキストが誤っているかもしれないという前提だけでなく、その結果が実際に起こり得るという前提で設計されなければならない。

simpliSOCはこの中でどう位置づけられるか。
私たちのsoc-integratorというFastAPIミドルウェアは、エージェントのすべてのツールをデフォルトで読み取り専用に設定し、自由形式の出力ではなく構造化されたverdictスキーマを強制し、エージェント生成のコンテンツをDFIR-IRIS内の不変で明確にラベル付けされた監査証跡として記録する——本記事で述べたコントロールは後付けの追加機能ではなく、パイプラインの設計そのものに組み込まれている。

agentic SOC導入についてセカンドオピニオンが欲しい、あるいは既存のWazuh + Shuffle + IRISスタックにこうしたガードレールを組み込む支援が必要な方は Simplicoにご相談ください →