偽のバグ報告でコーディングエージェントが乗っ取られる──「Agentjacking」が突いたMCP連携の死角

偽のエラー報告が、そのまま「実行命令」になる

セキュリティ企業の Tenet Security が2026年6月15日、AIコーディングエージェントを乗っ取る新たな攻撃手法を公表しました。攻撃者が仕込んだ偽のエラー報告を、エージェントが正規の修正指示と取り違えて実行してしまう、というものです。研究者はこれを「Agentjacking（エージェントジャッキング）」と名付けています。Cloud Security Alliance（CSA）も6月12日付の研究ノートで同じ問題を取り上げ、特定ツールの欠陥ではなく、ツール連携の仕組みそのものに根がある構造的な弱点だと整理しています。

標的になったのは、エラー監視サービス「Sentry」と、それを参照するコーディングエージェントの組み合わせです。Tenet の検証では Claude Code・Cursor・Codex の3つがいずれも被害を受け、攻撃の成功率は85%に達したとしています。

公開鍵ひとつで成立する攻撃の流れ

攻撃の起点は「DSN」と呼ばれる Sentry の識別子です。これはエラーを送信するための書き込み専用の鍵で、設計上フロントエンドのJavaScriptに埋め込まれて公開されています。攻撃者は認証なしでこの鍵を使い、偽のエラーを送り込めます。流れは次のとおりです。

• ① 公開サイトのJavaScriptやGitHub検索からDSNを見つける
• ② 認証不要のSentry受信口へ、偽のエラーイベントを送信する
• ③ エラー本文に、見出し・コードブロック・表として整形されたMarkdownを仕込む
• ④ 開発者が「Sentryの不具合を直して」とエージェントに依頼する
• ⑤ エージェントはMCP経由で偽イベントを取得し、正規の修正手順と解釈する
• ⑥ 攻撃者が用意したnpmパッケージを、開発者の権限で実行してしまう

整形された文章が「Sentry自身が出した解決手順」のように見える点が肝で、人間の目にも機械的な処理にも本物と区別しにくくなります。実行されたパッケージは、環境変数やAWSの鍵、GitHubトークン、Git認証情報などを抜き取れる、と報告されています。

影響範囲はどれくらいか

Tenet が公開した数値は次のとおりです。

「入口側では防げない」とするSentryの回答

注目すべきは、Sentry が根本的な修正に否定的な姿勢を示した点です。同社はこの攻撃を受信側（Sentry）で防ぐのは技術的に難しく、止められるのはエージェントが動く実行時しかない、という見解を示したと報じられています。エラー監視サービスは外部からの入力を受け取ることが本来の役割であり、その性質上、悪意ある投稿だけをはじくのは難しいためです。CSAも、MCPが外部データを「権威ある出力」として無検証で扱う信頼モデルそのものを、問題の核心に挙げています。

便利さの裏側にあるリスクと、いま取れる備え

コーディングエージェントにMCPで外部ツールをつなぐと、エラー対応や調査を任せられて効率は上がります。一方で、つないだ先のデータが「信頼できる指示」として扱われると、その経路がそのまま攻撃の入口になり得る――今回の件は、そうしたリスクを具体的に示した形です。便利さと攻撃面の拡大が裏表である点は、導入前に意識しておきたいところです。TenetとCSAが挙げる対策には、次のようなものがあります。

• 人間の承認をはさむ: MCP経由で得た内容からコマンドを実行する前に、開発者が必ず確認する。
• 権限を絞る: エージェントをサンドボックスで動かし、認証情報や環境変数へのアクセスを制限する。
• 連携を見直す: 不要なMCP連携は無効化し、露出したDSNはローテーションする。
• 依存と同じ目で見る: どのデータソースにつなぐかを、ソフトウェア依存の審査と同じ厳格さで評価する。

自動実行を広く許すほど、被害は広がりやすくなります。エージェントに任せる範囲と、人が止める箇所をあらかじめ設計しておくことが、当面の現実的な防御になりそうです。

参照: Tenet Security ／ Cloud Security Alliance ／ Cyber News Centre ／ The Hacker News