研究者たちが新たな証拠を示しました。AIコーディングエージェントが、認証情報の窃取やデータ改ざん、開発環境の侵害を狙う脅威アクターにとって、実行可能な攻撃対象になりつつあるということです。
Tenet Securityが実施した研究では、攻撃者が公開されているバグトラッキングサービスに偽のエラーレポートを1件仕掛けるだけで、AIコーディングエージェントを操作して開発者のマシン上で任意のコードを実行させられることが実証されました。同社が「エージェントジャッキング(agentjacking)」と名付けたこの手法を使った制御環境でのテストでは、Claude Code、Cursor、Codexといった広く普及しているAIコーディングアシスタントが、汚染されたエラーデータを取得し、多くのケースで攻撃者が制御するコードを開発者のマシン上で実行してしまいました。
偽のエラーレポートを使ったエージェントジャッキング
実際の攻撃では、クラウド認証情報、AWSキー、GitHubトークン、SSHキー、CI/CDパイプラインのシークレットなどが盗まれる恐れがあります。これらの認証情報を悪用されれば、攻撃者はプライベートなソースコードリポジトリへのアクセス、クラウドインフラの侵害、さらには組織全体のソフトウェア依存関係への汚染を引き起こせる可能性があります。
Tenet SecurityのCEO兼共同創業者であるBarak Sternberg氏は、組織にとってこの状況は深刻だと指摘します。「あなたが導入したAIエージェントは、今や最も脆弱な侵入経路になっています。しかも既存のセキュリティスタックにはそれが見えません」とSternberg氏は述べます。さらにエージェントジャッキングは特別巧妙な手法を必要とするわけではなく、偽のエラーレポート1つで成立すると付け加えます。「エージェントはそれを読み、信頼し、開発者自身のアクセス権限を使ってコードを実行しました。すべてのステップが正規の手順として処理されるため、IAM(アイデンティティ・アクセス管理)、EDR(エンドポイント検出・対応)、ネットワーク制御のいずれも検知できませんでした」
Tenetのエージェントジャッキングの実証は、開発者がアプリケーションのバグ、クラッシュ、ランタイムエラーを追跡するために広く使用しているエラートラッキング・アプリケーション監視サービス「Sentry」を対象に行われました。Sentryによれば、GitHub、Disney、Anthropic、Atlassianをはじめとする世界20万社以上の組織が同製品を利用しています。
Tenetの研究者は偽のエラーレポートを作成し、公開されているDSN(Data Source Name)を通じてSentryプロジェクトに送信しました。アプリケーションはDSNを使ってテレメトリデータをSentryインスタンスに送信しますが、この際にユーザー認証は不要です。多くの組織では、クライアントサイドアプリケーションがエラーやパフォーマンスデータを直接Sentryに報告できるよう、DSNを公開しています。Tenetは比較的容易に2,388もの組織が露出したSentry DSNを持っており、エージェントジャッキングの標的になり得ると主張しています。
Tenetがこのプロジェクトに注入した「エラー」は、正規のデバッグメッセージを装っていましたが、未解決のSentryイシューを調査するAIコーディングエージェントに影響を与えることを意図した隠し命令が含まれていました。Tenetの調査によると、開発者がModel Context Protocol(MCP)経由でSentryにクエリを実行するAIコーディングエージェントを使用した場合、そのエージェントが汚染されたエラーイベントを取得し、埋め込まれた命令を正当な診断ガイダンスとして扱ってしまうことが判明しました。Tenetによれば、対象となった事例の一つは時価総額2,500億ドル規模の企業だったとのことです。
AIエージェントに欠ける識別能力
Tenetのレポートが指摘する問題の根本は、AIコーディングエージェントが「読み込んだコンテンツ」と「実行すべき命令」を区別できないことにあります。MCPコネクタがドキュメント、メール、あるいは今回のようなエラーログといった外部ソースからコンテンツを取得する際、AIエージェントはすべてを入力として処理してしまいます。そのため、攻撃者が悪意ある命令を紛れ込ませることは容易です。
今年初めに開催されたRSAC 2026のブリーフィングでは、NetskopEの研究者が、ユーザーがAIアシスタントにメッセージの要約を依頼した際、悪意ある命令が書かれたメールをAIアシスタントが無条件に実行してしまうことを実証しました。
「重要な教訓は『Sentryにパッチを当てる』ということではありません」とSternberg氏は言います。「エージェントは読み込んだデータと実行命令を確実に区別できないということです。そして今やエージェントが読み込むデータには、テレメトリ、ログ、チケット、ツールの出力など、これまで誰も攻撃対象として考えたこともなかったものが含まれています」
設定変更の実施、信頼できない入力を無視するよう促すプロンプト、サンドボックス化、エージェントへのID付与といった対策はそれぞれ有効ですが、効果は限定的だとSternberg氏は続けます。「単独では機能しないか、あるいはエージェントを使い物にならなくしてしまいます。実際、エージェントに入力を信頼しないよう指示しても、ペイロードは実行されてしまいました」
Sternberg氏は、パッケージインストールスクリプトを無効化することに加え、エージェントがシェルコマンドを実行したり、読み込んだデータからインストールを行う前には人間による承認を必須とするよう推奨しています。また、エージェントには最小権限の原則を適用すべきとも述べています。長期的には、エージェントの意図をユーザーの元の意図とリアルタイムで照合し、エージェントが行動する瞬間に乖離を検知する能力の実装が必要です。「攻撃が、汚染されたデータに言われた通りのことを忠実に実行する信頼されたエージェントによって行われる場合、それを阻止できる唯一の場所はエージェントのランタイムです」
Action1のフィールドCTOであるGene Moody氏は、エージェントジャッキングのような攻撃は、AIモデルを完全に検証されるまで安全でない信頼できないものとして扱う必要性を示していると述べます。「ここで言う『検証済み』とは、ワークフローテストだけでなく、完全なセキュリティテストを意味します。それが完了した後も、モデル自体が攻撃ベクターになり得ることを考慮して、厳しく制限する必要があります。モデルが消費するデータの入力経路を制限し、それらにもゲートを設けるべきです」とMoody氏は言います。さらに、AIエージェントが本来の設計範囲を超えて考え行動する能力を制限する方法を検討することが重要だと指摘します。目指すべきは、AIエージェントが明示的に承認されていない指示に基づいて行動できないようにすることです。
翻訳元: https://www.darkreading.com/cyber-risk/fake-bug-report-hijacks-ai-coding-agents