AIコーディングエージェントは現在、開発者ラップトップおよびCI/CDパイプライン内で全セクターを通じて実行中です。開発者が監視していない場合でも、コードを記述し、コマンドを実行し、ファイルを読み取り、ネットワーク接続を確立することがよくあります。同じマシン上のほぼすべての他のソフトウェアとは異なり、通常のエージェント動作がどのように見えるかを理解する確立された検出層が存在しません。そのレベルでの攻撃がどのように見えるかは言うまでもありません。
Sysdig脅威研究チーム（TRT）がその層を構築することに着手しました。この記事は、我々が発見したことと、ランタイムセキュリティがこれらツールのセキュリティに対するアプローチの根本的な層である理由について説明します。
我々が調べた時に見たもの
これらのエージェントを検出するために何が必要であるか、そしてディフェンダーにとってそれらがどのように見えるかを理解することを開始しました。まず表面的なプロパティから始めて、3つの主要なエージェントそれぞれを実行する環境をインストルメント化し、SysdigとFalcoを使用してシステムコールレベルでそれらの動作をキャプチャしました。
高いレベルでは、セキュリティに関連する特性は明らかです。各エージェントは予測可能な場所に機密状態を格納します — ユーザーのホームフォルダ内の設定ディレクトリ（`~/.claude/`、`~/.gemini/`、`~/.codex/`）であり、APIトークン、セッションデータ、および設定を含んでいます。これらのディレクトリは同じユーザーで実行されているすべてのプロセスからアクセス可能です。エージェントは通常、呼び出し元ユーザーの完全なOS レベルの権限で動作し、エージェント自身のアプリケーションレベルの安全制御以上の機能制限はありません。エージェントの判断 — およびそれが実装するサンドボックス — は、プロンプトと特権システム操作の間の唯一のゲートです。
これらの表面的なプロパティを超えた検出を構築するために、システムコール層に移動しました。ここで異なる図が浮かび上がります — エージェントのユーザーインターフェースやログから見えないもの。
3つのエージェント、3つのランタイム
3つのエージェントは共通のエージェンティックループアーキテクチャを共有していますが、各々は異なるプロセスレベルのフィンガープリントを提示します。Claude Codeはバンドルされたオーケストレーターバイナリとして実行されます — その仕様プロセスはインストール固有パスのBun実行可能ファイルに解決されます。Gemini CLIはNode.jsスクリプトとして実行されます。つまり、そのオーケストレーターはシステムの共有Node インタプリタに解決されます。Codex CLIは一意の実行可能パスを持つスタンドアロンのRustバイナリにコンパイルされます。これらの違いにより、プロセス識別に対するエージェント非依存のアプローチは実用的ではなく、Falcoルールを使用してエージェント活動を確実に識別するために各インストールの詳細をマップしることが必要でした。
エージェンティックループ
3つのエージェントはすべて共通の実行パターンに従います。エージェントランタイムはそのLLM APIへの永続接続を維持します。モデルがツールを使用することを決定したとき — コマンドを実行、ファイルを読み取る、ネットワーク呼び出しを作成 — エージェントは指示をデシリアライズし、短命のシェルを生成してそれを実行し、結果を収集し、APIに送り返します。次にモデルが次に何をするかを決定します。このサイクルはモデルが最終的な応答を生成するまで繰り返されます。
システムコール層から、これは独特の反復的なイベントシーケンスとして現れます：
キャプチャされたセッションでは、10秒間でこのループの5回の反復を観測しました — 各々が単一のコマンドを実行して終了する使い捨てbashシェルを生成し、すべての反復間でAPIコールバックがありました。開発者は単一の応答を見ました。カーネルは64個の`execve`イベント、複数のアウトバウンドHTTPS接続、そして数レベル深いプロセスツリーを見ました。
これが異なる種類のセキュリティ課題である3つの理由
AIコーディングエージェントが提起するセキュリティ課題は、単に「監視する別のアプリケーション」ではありません。従来のエンドポイントセキュリティとは、検出エンジニアリングにとって重要な方法で異なります。
エージェントは構造的に脆弱です
LLMを搭載したエージェントは、十分に理解されたアーキテクチャ上の制限を共有しています。命令とデータの間に強固な分離がありません。ユーザー意図を伝える自然言語チャネルは、信頼されていないコンテンツ — リポジトリファイル、エラーメッセージ、依存関係ドキュメントも伝えます。エージェントが読む任意のソースにコンテンツを注入できる攻撃者は、その動作をリダイレクトできます。これは特定のエージェントの昨今ではなく、現在のLLMアーキテクチャがどのように入力を処理するかの構造的特性です。
プロンプトインジェクションはネットワークアクセス、悪用またはエスカレートされた権限を必要としません。コードファイル内の悪意のあるコメントまたは汚染された依存性READMEは、エージェントが認証情報にアクセス、データをエクスフィルトレート、または独自の構成を修正するのに十分です。
組み込みサンドボックスは誤った信頼の境界で動作します
各エージェントは内部安全制御を実装しています — 権限プロンプト、ファイルシステムサンドボックス、および承認ワークフロー。これらは多層防御アプローチに有用ですが、それらがエージェント自身のプロセス内で動作し、エージェント自身のコードによって実装されるため、本質的に制限されています。最近のインシデントは、エージェントがサンドボックス制限にもかかわらず機密ファイルにアクセスし、独自の権限システムを回避し、またはカバーされた機能をエスカレートするために構成を操作できることを実証しています。正常に操作されたエージェントは、攻撃の一部として独自の安全制御を無効にできます。
これらはこれらの制御の後ろのエンジニアリングに対する批判ではありません。それはセキュリティの信頼の境界についての声明です：アプリケーションレベルのサンドボックスはサンドボックス自身と同じ権限レベルで動作する脅威から保護することはできません。
確定的なプログラムからプロンプト駆動アクターへ
従来のランタイムセキュリティ監視は、プログラムの実行可能なロジックがその機能的な限界を定義するという前提に依存しています。複雑なソフトウェアであっても、プログラムのコードが可能なアクションの範囲を支配するため、動作ベースラインは通常確立できます。
AIコーディングエージェントはこのモデルにうまく適合していません。エージェントは、呼び出し元ユーザーがアクセス権を持つ任意のファイルを読み取り、任意のプロセスを生成し、任意のネットワーク呼び出しを行うことができます。その動作はそのコードによってではなく、すべての相互作用で変更されるプロンプトによって決定されます。この点で、エージェントはインタラクティブユーザーに近いです。それらは、バイナリだけからは予測できないアクセスパターンを持つ汎用アクターです。これにより、プログラムがすべきことを定義し、逸脱に対してアラートを発する標準的なアプローチが複雑になります。これは、エージェントの場合、正当な動作の空間が、設計上、非常に広いためです。
カーネルレベル監視の場合
上記の考慮事項 — プロンプトインジェクションへの構造的脆弱性、アプリケーションレベルサンドボックスの信頼性の制限、および動作的ベースラインの確立の困難さ — エージェント動作の監視がエージェント自身が影響を及ぼすことができない条件で観測可能性を必要とすることを示唆しています。
eBPFを介したシステムコールレベルの検査は、FalcoおよびSysdigのランタイム検出エンジンを支えており、従来のワークロードに対してこれをすでに提供しています。プロセスツリー全体のシステムイベントをキャプチャし、監視されるアプリケーションに関わらず動作し、プロセス親子関係の帰属を公開します。多くの既存検出 — リバースシェル、データエクスフィルトレーションパターン、権限エスカレーションシーケンス — 変更なしにエージェントが開始したアクティビティに適用されます。
したがって、我々は隙間をカバーすることに優先順位を付けました：エージェントの使用が導入する新しい攻撃表面。
脅威を観測可能な動作にマッピングする
AIコーディングエージェントの脅威モデルはまだ形成中です。新しい攻撃テクニック、ツール、実世界のインシデントは、業界の主体的対応能力に課題をもたらすペースで文書化されています。迅速に検出戦略を考案するために、我々はこれまでに文書化されている攻撃シナリオ全体で高信頼度インジケーターを表す4つの観測可能な動作を特定しました。それぞれが特定の検出ルールに対応し、攻撃の起源または高度に関係なく、システムコール層で観測可能な動作に的を絞っています。
新しい検出カバレッジを構築する際に考慮に入れた1つの重要な設計原則があります：検出は、それを生成した攻撃ベクトルではなく、観測可能な動作に固定されています。プロンプトインジェクション、文脈汚染、MCPサーバー悪用は異なる攻撃方法ですが、システムコール層では、同じ結果で収束できます — エージェントプロセスがそうすべきでないファイルを読み取ります。この原則は、攻撃変種全体で検出を耐久的にするものです。
プロンプトインジェクション経由のエージェント操作
これまでコーディングエージェントに対して最も広く文書化された攻撃クラスは、プロンプトインジェクションです：リポジトリファイル、エラーメッセージ、依存関係ドキュメント、MCPサーバー応答などのエージェントが処理するコンテンツに埋め込まれた敵対的指示。エージェントは注入された指示をそのタスクの一部として解釈し、それに対処します。
我々が検出する結果はインジェクション自体ではなく — それはLLMの推論内で発生し、カーネルの可視性外ですが — その結果のシステムレベルの動作です。実際、操作されたエージェントは依然として攻撃者の意図を実行するためのシステムコールを発行する必要があります：認証情報ファイルの読み取り、予期しないプロセスの生成、ネットワーク接続の開放、他のエージェント構成ディレクトリへのアクセス。
この攻撃パターンは既に悪用されています。PromptArmorはSlack AIに対する間接的プロンプトインジェクション（ATLAS AML.CS0035）を文書化しました。メッセージに埋め込まれた指示は認証情報エクスフィルトレーションを引き起こしました。Backslash Securityは悪意のあるMCPサーバー経由でCursor IDEへの直接的な攻撃（ATLAS AML.CS0045）を文書化しました。プロンプトインジェクションはcurl経由で認証情報をエクスフィルトレートするシェルコマンドを実行しました。プロンプトインジェクション攻撃分類システムなどのプロジェクトは、同様のテクニックの成長するカタログを保つています。各場合に、攻撃はシステムコール層活動で終わります — プロセス生成、ファイル読み取り、アウトバウンド接続 — これらは我々のルールが検出するように設計されています。
エージェント設定をターゲットにした認証情報盗難
エージェント構成ディレクトリには、LLMアカウント、会話履歴、そして場合によっては請求インフラへの直接アクセスを提供するAPIトークンが含まれています。これらのトークンはユーザーのホームディレクトリ内の予測可能なパスに保存されます — これはそのユーザーで実行されているすべてのプロセスの直接的なターゲットにしている特性です。
我々の検出は前のカテゴリとは異なる境界をターゲットにしています：ここで、脅威はエージェント外部です。エージェント構成ディレクトリに対してファイルI/Oを実行するエージェント独自のプロセスファミリー外のプロセスがこの検出をトリガーします。これは不正アクセス自体に固定されています — 使用されたツール、その起源、またはその後に何をするかに関係なく発火します。
盗まれたエージェント認証情報の下流の意味合いはますます明らかになってきています。2025年7月、Microsoft DARTはSesameOp（ATLAS AML.CS0042）を文書化しました。OpenAI Assistants APIを暗号化されたコマンド・コントロールチャネルとして使用した悪意のあるソフトウェア。これは、LLM APIが秘密のC2として転用された初の確認されたケースでした。オペレーターはトラックをカバーするために操作後のAPI関連の書類を削除しました。エージェント認証情報が既に存在する侵害された開発者マシンは、攻撃者に独自にプロビジョニングすることなくLLM APIへの事前認証されたチャネルを与えます。
安全制御のバイパス
各エージェントは組み込みの安全制御を無効にするコマンドラインフラグを提供しています — 権限プロンプト、サンドボックス、および承認ワークフロー。これらのフラグはトラストされた環境での自動化を目的としていますが、エージェントをどのように起動するか影響を与えることができる人によって悪用される可能性があります：侵害されたシェルエイリアス、修正されたCI構成、または操作された環境変数。
これはルールセット内で最も直接的な検出です：エージェント呼び出しで既知の危険フラグのproc.cmdlineと照合します。それはまた最も即座に実行可能です — アラートはエージェントが任意の操作を実行する前に発火し、下流の影響が発生する前に介入する機会を提供します。
我々はこれをサンドボックス関連検出の開始点と見なしています。サンドボックスエバージョンの動作パターンへのより深い研究 — 明示的なフラグではなく間接的な手段を通じて独自の安全制御を回避するエージェント — は継続中の研究の領域です。
インフラストラクチャ上のエージェント存在
エージェント固有の脅威を検出する前に、エージェントが存在することを知る必要があります。インストール検出はアセット在庫ベースラインを提供します。この検出はパッケージマネージャー、ダウンロードツール、またはインストーラースクリプトがエージェントインストール署名と一致するプロセスを生成する時に発火します。
これは情報ルールですが、基礎的な役割を果たします。AIコーディングエージェントがインフラストラクチャ上にあると予期しない組織は、任意のインストールイベントを不正な配置として扱うことができます。そうするものはインベントリとコンプライアンス追跡に使用できます。
エージェントを理解する検出の構築
我々の検出戦略は上述の観察と脅威モデルから直接的に従います。我々はエージェントが意図する操作を解釈しようとしたり、プロンプトを良性または悪意のあるものとして分類したりしようとしません。代わりに、我々はエージェントをOSレベルで何が — 特権プロセスと観測可能な動作を持つ — 見なし、従来のワークロードのランタイムセキュリティをガイドしている同じ原則を適用します：何が起こってはならないかを定義し、それが起こった時に検出します。
最初の課題は帰属です。エージェントはプロセステーブルで自身を発表しません。Bunバイナリ、Nodeインタプリタ、Rust実行可能ファイル — これらのいずれも、同じランタイムを使用している他のソフトウェアと区別する特定のインストールパスおよびプロセス親子関係チェーンを理解することなく、本質的にAIエージェントとして識別可能ではありません。この識別問題をエージェントごと、それらの様々なインストール方法全体で解決することは、すべての他の必須条件です。信頼できる帰属がなければ、エージェント固有の検出は不可能です。
身元が確立されると、ルール自体は意図的に直感的です。4つの動作パターン — インストール、不正な構成アクセス、機密ファイル読み取り、安全制御バイパス — すべての3つのエージェント全体で対称的に適用され、MITRE ATT&CKおよびATLASにマップされ、本番ワークロードに対して調整されています。複雑さは個々のルールにではなく、その下のインフラストラクチャにあります：プロセス識別層、マルチシステムコールファミリーカバレッジ、および開発者VMからKubernetesクラスターまでのの環境にデプロイ可能にする例外フレームワーク。
我々がカバーする4つのパターンは高信頼度、即座に実行可能な検出を表しています — しかし、エージェンティックAIシステムの完全な脅威表面はそれらをはるかに超えています。脅威モデルが成熟するにつれて、新しい攻撃テクニックが文書化されるにつれて、エージェントがクラウドインフラストラクチャへの深い統合を獲得するにつれて、ルールセットは成長する必要があります。我々が構築した基礎 — エージェントごとのプロセス識別、本番チューニング例外、体系的なMITREマッピング — その進化をサポートするように設計されています。ルールはSysdig Secureの顧客が管理されたFalcoルールフィードを通じて利用可能です。
今後：攻撃表面の拡大とエージェント供給チェーンの台頭
エージェント化システムがスケールおよび相互接続されるにつれて、それらのリスク分布は著しく拡大します。
マルチエージェントパイプラインは単一のプロンプトインジェクションの影響を増幅し、汚染されたデータをワークフロー全体で伝播するのを許可します。同時に、MCPエコシステムは新しい種類の供給チェーンとして出現しています。侵害されたサーバーは1回のイベントではなく、プロンプトインジェクションまたはデータエクスフィルトレーションの継続的なチャネルになります。初期MCPの脆弱性（CVE-2025-53109およびCVE-2025-53110）はこのリスクが既に実体化していることをハイライトしています。
検出はそれに応じて進化する必要があります。動作プロファイリング — システムコール層でのエージェント活動の通常の外観を理解し、逸脱をフラグします — は有望な道ですが、依然として進行中の課題です。これはエージェントが開発者マシンからCI/CDパイプラインおよびクラウド環境に移動するにつれて、そこでしばしば機密認証情報および本番システムへのアクセスを持つ際に、より重要になります。
非決定的動作、継承されたOS権限、および広範なデータ露出の組み合わせは、既存のディフェンスが対処するために構築されなかった脅威モデルをリスクします。
検出原則は耐久的です：エージェントがOSレベルで何をするかを監視し、各々について通常がどのように見えるかを理解し、インフラストラクチャ上の他のすべての特権プロセスに与えるのと同じ重大さで逸脱を扱います。
それらが正確に何であるかが理由で。
付録：脅威インテリジェンスフレームワーク
MITRE ATLAS
MITRE ATLAS（人工知能システム向けの敵対的脅威ランドスケープ）は、ML システムの完全な攻撃ライフサイクルをカバーする16のAI固有の戦術および80を超える技術でATT&CKを拡張しています。コーディングエージェントに最も関連する戦術：
- AML.TA0004 — 初期アクセス：悪意のあるパッケージ、スロップスクワッティング、汚染されたMCPサーバーを通じた供給チェーン侵害
- AML.TA0005 — 実行：ドキュメント、ウェブコンテンツ、またはMCPツール出力経由の間接的プロンプトインジェクション（AML.T0051.001）；エージェントツール呼び出し（AML.T0053）シェルおよびAPIの悪用
- AML.TA0006 — 永続性：セッション全体のメモリ毒殺（AML.T0080.000）；エージェント構成修正（AML.T0081）永続的な指示を注入する
- AML.TA0013 — 認証情報アクセス：エージェント構成ファイルからの認証情報（AML.T0083）— `~/.claude/`、`~/.cursor/`、`~/.codex/`に保存されるAPIキー
- AML.TA0007 — ディフェンスエバージョン：プロンプト難読化（AML.T0068）base64、隠しHTML経由；LLM越え（AML.T0054）安全ガードレール
- AML.TA0014 — コマンド・コントロール：リバースシェル（AML.T0072）；LLM API秘密C2（SesameOp）
ATLASケーススタディライブラリ（52の文書化されたケース）にはAML.CS0045（Cursor MCP）、AML.CS0035（Slack AI）、およびAML.CS0040（ChatGPT記憶毒殺）が含まれています — 我々の検出ロジックを直接知らせた文書化された攻撃チェーン。
ATLASケーススタディ — コーディングエージェントに関連する実際のインシデント
- AML.CS0035：Slack AIへの間接的プロンプトインジェクション — 埋め込まれた指示は欺瞞的URLレンダリング経由での認証情報エクスフィルトレーションを引き起こしました
- AML.CS0040：Google DocのGoogleドキュメント経由での間接的プロンプトインジェクション経由でのChatGPT記憶毒殺 — 永続的なセッション間指示注入
- AML.CS0042：SesameOp（Microsoft DART）— 暗号化されたC2チャネルとしてOpenAI Assistants APIを使用した実際のマルウェア；初の確認されたLLM API-as-C2インシデント
- AML.CS0045：Cursor + 悪意のあるMCPサーバー — プロンプトインジェクション実行 `~/.cursor/mcp.json`から認証情報をエクスフィルトレートするbase64エンコードされたシェルコマンド
OWASP LLM Top 10
OWASP LLM Top 10はLLM統合アプリケーションの重要な脆弱性クラスをマップしています。3つのカテゴリが直接適用されます：
- LLM01 — プロンプトインジェクション：最優先リスク。直接および間接的インジェクションをカバーします。OWASPはMCPサーバーおよび外部ツール統合を高リスク注入表面として明示的にフラグします。
- LLM06 — 過度な代理：より多くの権限または自律性を持つエージェント：いずれのタスクも必要です。すべての他の脆弱性を増幅します。我々の安全制御バイパス検出パターンに直接マップしています。
- LLM08 — ベクトルおよび埋め込み脆弱性：汚染されたRAGデータベースは取得機能を持つエージェントのための永続的な注入チャネルになります。
Googleセキュアファイフレームワーク（SAIF）
Google SAIFはAIシステムの動作監視を必要なセキュリティ制御として特定しています。その6つのコア要素中2つは直接的に整列しています：*AIを組織の脅威ユニバーサに持ち込むための検出および応答を拡張* および *既存および新しい脅威に対するペースを維持するためのディフェンスを自動化* — 非決定的エージェント動作のための唯一の効果的検出層がランタイムセキュリティであることが我々の結論と一致しています。
クラウド検出 & 応答
