AIコーディングエージェントは現在、開発者のラップトップやCI/CDパイプライン内で、あらゆるセクターを通じて動作しています。これらはコードを記述し、コマンドを実行し、ファイルを読み取り、ネットワーク接続を行います。多くの場合、開発者が見守ることなく。同じマシン上にあるほぼ他のすべてのソフトウェアとは異なり、エージェントの正常な動作がどのようなものかを理解する確立された検出層は存在しません。言うまでもなく、その段階での攻撃がどのようなものかを理解する層も存在しません。
Sysdigの脅威研究チーム（TRT）は、その層を構築することにしました。この記事は私たちが発見したことと、なぜランタイムセキュリティがこれらのツールのセキュリティに対する根本的な層であるのかをカバーしています。
私たちが見たもの
これらのエージェントを検出するために何が必要かを理解し、防御者の視点からどのように見えるかを開始しました。まず表面レベルのプロパティから始めて、3つの主要なエージェントそれぞれを実行している環境をインストルメント化し、Sysdigおよびfalcoを使用してシステムコールレベルで動作をキャプチャしました。
高いレベルでは、セキュリティ関連の特性は明白です。各エージェントは機密状態を予測可能な場所に保存します — ユーザーのホームフォルダ内の設定ディレクトリ（`~/.claude/`、`~/.gemini/`、`~/.codex/`）で、APIトークン、セッションデータ、設定を含んでいます。これらのディレクトリは同じユーザーで実行している任意のプロセスからアクセス可能です。エージェントは通常、エージェント独自のアプリケーションレベルの安全制御を超えた能力制限なしで、呼び出し元ユーザーのフルOSレベルの権限で動作します。エージェントの判断 — およびそれが実装するサンドボックス — はプロンプトと特権システム操作の間の唯一のゲートです。
これらの表面的なプロパティを超えて検出を構築するために、私たちはシステムコール層に移りました。ここで異なる画像が浮かび上がります — エージェントのユーザーインターフェースまたはログから見えないものです。
3つのエージェント、3つのランタイム
3つのエージェントは共通のエージェントループアーキテクチャを共有していますが、それぞれが異なるプロセスレベルのフィンガープリントを提供します。Claude Codeはバンドルされたbunバイナリとして実行されます — そのオーケストレーターのプロセスはインストール固有のパスのbun実行ファイルに解決されます。Gemini CLIはNode.jsスクリプトとして実行されます。つまり、そのオーケストレーターはシステムの共有ノードインタープリターに解決されます。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）を文書化しました。ここで、メッセージに埋め込まれた指示は認証情報流出を引き起こしました。バックスラッシュセキュリティは悪意のある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バイナリ、ノードインタープリター、Rust実行可能ファイル — これらのどれもが、これらの同じランタイムを使用している他のソフトウェアと区別するために特定のインストールパスとプロセス起源チェーンを理解することなく、本質的にAIエージェントとして識別できません。エージェントごと、その様々なインストール方法を通じてこのID問題を解決することは、他のすべてのための前提条件です。信頼できる帰属がなければ、エージェント固有の検出は不可能です。
ID が確立されたら、ルール自体は意図的に単純です。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 — 防御回避：base64、隠しHTMLを通じたプロンプト難読化（AML.T0068）；安全ガードレールをバイパスするLLMジェイルブレイク（AML.T0054）
- AML.TA0014 — コマンドおよびコントロール：リバースシェル（AML.T0072）；隠しC2としてのLLM API（SesameOp）
ATLASケーススタディライブラリ（52の文書化されたケース）には、AML.CS0045（Cursor MCP）、AML.CS0035（Slack AI）、およびAML.CS0040（ChatGPT記憶ポイズニング）が含まれています — 私たちの検出ロジックを直接通知する文書化された攻撃チェーン。
ATLASケーススタディ — コーディングエージェントに関連する実際のインシデント
- AML.CS0035：Slack AIへの間接的なプロンプトインジェクション — 埋め込まれた指示は欺瞞的なURL描画を通じて認証情報流出を引き起こしました
- AML.CS0040：Google Docでの間接的なプロンプトインジェクション経由のChatGPT記憶ポイズニング — 永続的なクロスセッション指示注入
- AML.CS0042：SesameOp（Microsoft DART）— OpenAI Assistants APIを暗号化されたC2として使用した実マルウェア；最初に確認された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セキュアなAIフレームワーク（SAIF）
Google SAIFはAIシステムの動作監視を必要なセキュリティ制御として識別します。そのコア要素の2つが直接整列します：*AIの脅威ユニバースへの組織の脅威検出と対応を拡張する*および*既存および新しい脅威と同ペースで防御を自動化する* — 私たちの結論と一致して、ランタイムセキュリティは非決定論的エージェント動作の唯一の効果的な検出層です。
クラウド検出および対応
