Falco Feedsは、オープンソースに焦点を当てた企業に、新しい脅威が発見されると継続的に更新される専門家が作成したルールにアクセスできるようにすることで、Falcoの力を拡大します。
本文の内容は、2026年3月23日に Miguel Hernández が投稿したブログ(https://www.sysdig.com/blog/ai-coding-agents-are-running-on-your-machines-do-you-know-what-theyre-doing) を元に日本語に翻訳・再構成した内容となっております。
AIコーディングエージェントは現在、あらゆる業界において開発者のラップトップ上やCI/CDパイプライン内で稼働しています。これらはコードを書き、コマンドを実行し、ファイルを読み取り、ネットワーク接続を行いますが、多くの場合、開発者の監視なしに動作します。同じマシン上で動作するほとんどの他のソフトウェアとは異なり、エージェントの正常な挙動がどのようなものか、さらにはそのレベルで攻撃がどのように見えるのかを理解するための確立された検知レイヤーは存在していません。
Sysdig 脅威リサーチチーム（TRT）は、このレイヤーを構築することを目的としました。本記事では、我々が発見した内容と、これらのツールのセキュリティに取り組む上でランタイムセキュリティが基本的なレイヤーである理由について説明します。
調査で確認された内容
これらのエージェントを検知するために何が必要か、そして防御側からどのように見えるのかを理解することを目的としました。まず、それらの表面的な特性から着手し、その後、3つの主要なエージェントそれぞれを実行する環境に計測を組み込み、SysdigおよびFalcoを用いてシステムコールレベルでその挙動を記録しました。
大まかに言えば、セキュリティ上重要な特性は単純です。各エージェントは機密状態を予測可能な場所に保存します。すなわち、ユーザーのホームフォルダ内の設定ディレクトリ（~/.claude/、~/.gemini/、~/.codex/）にAPIトークン、セッションデータ、設定情報を格納しています。これらのディレクトリには、同一ユーザーで実行される任意のプロセスがアクセス可能です。エージェントは通常、呼び出し元ユーザーのOSレベルの完全な権限で動作し、エージェント自身のアプリケーションレベルの安全制御以外に機能制限はありません。エージェントの判断、およびそれが実装するサンドボックスこそが、プロンプトと特権的なシステム操作の間に存在する唯一の防御線です。
これらの表面的な特性を超えた検知を構築するために、我々はシステムコールレベルへと移行しました。ここでは、エージェントのユーザーインターフェースやログからは見えない、異なる姿が浮かび上がります。
3 つのエージェント、3 つのランタイム
3つのエージェントはいずれも共通のエージェントループアーキテクチャーを共有していますが、プロセスレベルではそれぞれ異なる特徴を示します。Claude CodeはバンドルされたBunバイナリとして実行され、そのオーケストレータプロセスはインストールごとのパスに存在する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コーディングエージェントはこのモデルにはうまく当てはまりません。エージェントは、呼び出し元ユーザーがアクセス可能なあらゆるファイルを読み取り、あらゆるプロセスを生成し、あらゆるネットワーク呼び出しを行うことができます。その挙動はコードによってではなく、やり取りごとに変化するプロンプトによって決定されます。この点において、エージェントは従来のプログラムというよりも対話的なユーザーに近い存在です。これらは汎用的なアクターであり、そのアクセスパターンはバイナリだけから予測することはできません。このため、プログラムが本来行うべき動作を定義し、その逸脱を検知するという従来のアプローチは複雑になります。エージェントの場合、正当な挙動の範囲が設計上非常に広いためです。
カーネルレベルでの観測の必要性
前述の検討事項 — プロンプトインジェクションに対する構造的な脆弱性、アプリケーションレベルのサンドボックスの信頼性の限界、そして挙動のベースライン確立の困難さ — は、エージェントの挙動を監視するには、エージェント自身が影響を及ぼせないレベルでの可観測性が必要であることを示しています。
FalcoやSysdigのランタイム検知エンジンを支えるeBPFによるシステムコールレベルの計測は、従来のワークロードに対してすでにこれを提供しています。これはプロセスツリー全体にわたるシステムイベントを取得し、監視対象のアプリケーションから独立して動作し、属性付けのためのプロセスの系譜を可視化します。既存の多くの検知 — リバースシェル、データ流出パターン、特権昇格シーケンス — は、エージェントによって引き起こされるアクティビティにも修正なしで適用可能です。
したがって、我々はそのギャップ、すなわちエージェントの利用によって新たに生じる攻撃対象領域のカバーを優先しました。
脅威を観測可能な挙動にマッピングする
AIコーディングエージェントに対する脅威モデルは、現在も形成途上にあります。新たな攻撃手法、ツール、実際のインシデントが、業界がそれらに先回りして対応する能力を試す速度で次々と報告されています。検知戦略を迅速に策定するために、これまでに報告されている攻撃シナリオ全体において、高い信頼性の指標となる4つの観測可能な挙動を特定しました。それぞれは特定の検知ルールに対応しており、攻撃の発生源や高度さに関係なく、システムコールレベルで観測可能な挙動を対象としています。
新たな検知カバレッジを構築するにあたり、我々が考慮した重要な設計原則が1つあります。それは、検知は攻撃ベクトルではなく、観測可能な挙動に基づいて行うという点です。プロンプトインジェクション、コンテキストポイズニング、MCPサーバーの悪用はそれぞれ異なる攻撃手法ですが、システムコールレベルでは同じ結果、すなわち本来アクセスすべきでないファイルをエージェントプロセスが読み取るという挙動に収束する可能性があります。この原則こそが、攻撃のバリエーションに対しても有効な検知を可能にします。
プロンプトインジェクションによるエージェント操作
これまでにコーディングエージェントに対して最も広く報告されている攻撃クラスは、プロンプトインジェクションです。これは、リポジトリファイル、エラーメッセージ、依存関係のドキュメント、MCPサーバーの応答など、エージェントが処理するコンテンツ内に埋め込まれた敵対的な指示です。エージェントはこの注入された指示を自身のタスクの一部として解釈し、それに従って動作します。
我々が検知するのはインジェクションそのものではありません。インジェクションはLLMの推論の内部で発生し、カーネルからは可視ではないためです。我々が検知するのは、その結果として生じるシステムレベルの挙動です。実際、操作されたエージェントであっても、攻撃者の意図を実行するためにはシステムコールを発行する必要があります。すなわち、認証情報ファイルの読み取り、予期しないプロセスの生成、ネットワーク接続の確立、他のエージェントの設定ディレクトリへのアクセスといった動作です。
この攻撃パターンはすでに実際に悪用されています。PromptArmorは、メッセージに埋め込まれた指示が認証情報の流出を引き起こしたSlack AIに対する間接的なプロンプトインジェクション（ATLAS AML.CS0035）を報告しています。Backslash Securityは、悪意のあるMCPサーバーを介してCursor IDEに対して行われた直接的な攻撃（ATLAS AML.CS0045）を報告しており、この攻撃ではプロンプトインジェクションによってシェルコマンドが実行され、curlを通じて認証情報が流出しました。Prompt Injection Attack Classification Systemのようなプロジェクトは、同様の手法のカタログを継続的に拡充しています。いずれのケースでも、攻撃は最終的に、プロセスの生成、ファイルの読み取り、アウトバウンド接続といった、我々のルールが検知するよう設計されたシステムコールレベルで観測可能なアクティビティに帰着します。
エージェント設定を標的とした認証情報の窃取
エージェントの設定ディレクトリには、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マッピング — は、その進化を支えるために設計されています。これらのルールは、マネージドFalcoルールフィードを通じてSysdig Secureの顧客に提供されています。
今後の展望：拡大する攻撃対象領域とエージェントサプライチェーンの台頭
エージェント型システムが拡大し相互接続されるにつれて、そのリスクプロファイルは大きく拡大します。
マルチエージェントパイプラインは、単一のプロンプトインジェクションの影響を増幅し、侵害されたデータがワークフロー全体に伝播することを可能にします。同時に、MCPエコシステムは新たな種類のサプライチェーンとして台頭しています。侵害されたサーバーは一度きりの事象ではなく、プロンプトインジェクションやデータ流出の継続的なチャネルとなります。初期のMCPの脆弱性（CVE-2025-53109およびCVE-2025-53110）は、このリスクがすでに現実のものとなりつつあることを示しています。
これに応じて、検知も進化する必要があります。挙動プロファイリング、すなわちシステムコールレベルでのエージェントの正常な挙動を理解し、その逸脱を検知する手法は有望なアプローチですが、依然として進行中の課題です。これは、エージェントが開発者のマシンからCI/CDパイプラインやクラウド環境へと移行するにつれて、さらに重要になります。これらの環境では、エージェントが機密な認証情報や本番システムにアクセスできることが多いためです。
非決定的な挙動、継承されたOS権限、広範なデータへのアクセスという組み合わせは、既存の防御では対応することを前提としていなかったリスクモデルを生み出します。
検知の原則は不変です。エージェントがOSレベルで何をしているのかを監視し、それぞれにとっての正常な挙動を理解し、その逸脱をインフラ上の他の特権プロセスと同様の重要度で扱うことです。
なぜなら、これらのエージェントはまさにそのような存在だからです。
付録:脅威インテリジェンスフレームワーク
MITRE ATLAS
MITRE ATLAS（Adversarial Threat Landscape for Artificial-Intelligence Systems）は、ATT&CKを拡張し、16のAI特有の戦術と80以上の技術を含み、MLシステムに対する攻撃ライフサイクル全体をカバーしています。コーディングエージェントに最も関連する戦術は以下の通りです。
- AML.TA0004 — 初期アクセス：悪意のあるパッケージ、スロップスクワッティング、改ざんされたMCPサーバーによるサプライチェーン侵害
- AML.TA0005 — 実行：ドキュメント、ウェブコンテンツ、またはMCPツールの出力を介した間接的なプロンプトインジェクション（AML.T0051.001）；シェルやAPIを悪用したエージェントのツール呼び出し（AML.T0053）
- 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がC2として利用された初の確認事例
- AML.CS0045：Cursor + 悪意のあるMCPサーバー — プロンプトインジェクションにより、base64エンコードされたシェルコマンドが実行され、~/.cursor/mcp.jsonから認証情報が流出
OWASP LLM Top 10
OWASP LLM Top 10は、LLM統合アプリケーションにおける重大な脆弱性の分類を示しています。以下の3つのカテゴリが直接該当します。
- LLM01 — プロンプトインジェクション：最優先のリスク。直接および間接のインジェクションを対象とします。OWASPは、MCPサーバーや外部ツール統合を高リスクのインジェクション表面として明示的に指摘しています。
- LLM06 — 過剰なエージェンシー：タスクに必要以上の権限や自律性を持つエージェントは、他のすべての脆弱性を増幅させます。我々の安全制御回避の検知パターンに直接対応します。
- LLM08 — ベクトルおよび埋め込みの弱点：汚染されたRAGデータベースは、検索機能を持つエージェントにとって持続的なインジェクションチャネルとなります。
-
Google Secure AI Framework (SAIF)
Google SAIFは、AIシステムに対する挙動監視を必要なセキュリティ対策として位置付けています。その6つの中核要素のうち、2つが直接対応します。すなわち、「AIを組織の脅威領域に取り込むために検知と対応を拡張すること」と、「既存および新たな脅威に対応するために防御を自動化すること」です。これは、非決定的なエージェントの挙動に対して有効な検知レイヤーはランタイムセキュリティのみであるという我々の結論と一致しています。