公開DSNから偽のSentryエラーを注入し、AIコーディングエージェント(Claude Code / Cursor / Codex)に攻撃者のコードを開発者権限で実行させる新攻撃「Agentjacking」。Sentryは「技術的に防御不能」として修正せず。4月のシャドーAI記事の懸念が実証された今、防御は監視ではなく「抜かれても破綻しない構造」の設計へ。
2026年4月、このコミュニティで 「本当の敵はシャドーAIだった」 という記事を書きました。
その中で、こう書いていました。
AIは「ツールを使う」ことができる。
.envを読める、外部APIを叩ける、シェルコマンドを実行できる。これは AI が悪意を持っているかどうかの話ではなく、仕組みとして防げない。
2か月後の2026年6月12日、その懸念をそのまま実証する攻撃が公表されました。Agentjacking です。
セキュリティ企業 Tenet Security が命名した、新しいクラスの攻撃です。標的は、開発者が信頼している AIコーディングエージェント そのもの。
攻撃チェーンはこうです。
| 手順 | 内容 |
|---|---|
| ① | 攻撃者が標的の Sentry DSN(Webサイトに埋め込まれた、イベント送信(取り込み)専用の公開キー)を見つける |
| ② | その DSN を使い、Sentryのイベント取り込みエンドポイントに 偽のエラーイベント をPOSTする |
| ③ | 偽イベントの message フィールドに、Sentryのシステムテンプレートと見分けがつかない細工Markdownを仕込む |
| ④ | 開発者が「未解決のSentry issueを直して」とAIエージェントに頼む |
| ⑤ | エージェントがMCP経由でSentryを照会 → 偽イベントを受け取り、攻撃者のコードを「修正手順」として開発者権限で実行 |
ポイントは、攻撃者は標的のインフラに一切触れないことです。フィッシングも、サーバー侵害も要らない。組織が自分で公開しているデータ(DSN)だけを使う。
成功すれば、環境変数、Git認証情報、プライベートリポジトリURL、開発者のアイデンティティが露出します。Tenetの実証では、~/.aws/config、~/.npmrc、~/.docker/config.json へのプローブまで確認されています。
Tenetの検証では、注入可能なDSNが露出した組織が少なくとも2,388件見つかり、100超の組織に対する制御下のテストで 85%の悪用成功率 を記録しました。対象には Claude Code、Cursor、Codex といった主要なAIコーディングアシスタントが含まれます。
そしてSentry側の回答は——「技術的に防御不能」として、修正しない。グローバルな特定文字列フィルタを有効化したのみです。
ここが核心です。
AIエージェントは、MCPで繋がった外部サービスの出力を 信頼すべき情報 として扱います。エラーイベントが本物のクラッシュ由来か、攻撃者が注入したものか、エージェントには区別できません。区別できないまま「これが直し方です」と書かれていれば、その通りに動く。
つまり、疑わずに指示を実行することがエージェントの仕事であり、その仕事を真面目にやるほど騙される。これは設定ミスでもバグでもありません。
そして、これは Sentry固有の問題ではありません。GitHub issues、サポートチケット、webhook——信頼できないコンテンツがエージェントのコンテキストに流れ込む経路すべてに、同じ構造が存在します。Sentryは最初の実証例にすぎない。
この構造、ラグビーのディフェンスにそっくりです。
攻撃側はダミーパスや偽のコールでディフェンスを崩しにきます。個々のプレイヤーは、聞こえたコールを信じて動くのが役目です。だから、巧妙なフェイントに個人が抜かれること自体は、完全には防げない。エージェントが偽の「修正手順」を信じて動くのと同じです。
では、コーチが全員を監視すればいい?——できません。コーチは試合中ピッチに立てない。人間が、すべてのエージェントの、すべての実行を、リアルタイムで監視する。それは現実に不可能だし、もしそれをやるなら、そもそもAIに任せる意味がありません。
答えは、監視を強めることではありません。
個人(プレイヤー=エージェント)が抜かれても、ディフェンスシステム全体としては破綻しない。
そういう構造を組むこと。個人技ではなく、構造で守る。
実は、この発想はセキュリティの世界では古くからあります。Assume Breach(侵害を前提とする) という考え方です。
少し違う例ですが——動画配信のDRMも同じ哲学です。「完全には防げない」という前提に立ち、ウォーターマークや視聴者追跡で「抜かれても被害を限定できる/誰が漏らしたか特定できる」設計にしている。完璧な壁を作るのではなく、破られた後の構造で守る。
エージェント時代のセキュリティも、これと同じ地点に来ました。
具体的には、こういうレイヤーです。
| レイヤー | やること |
|---|---|
| 可視化 | どのエージェントが、どのMCPサーバーに繋がっているかを把握する |
| 最小権限 | エージェントが触れる範囲(認証情報・実行権限)を最初から絞る |
| 実行ガードレール | 「外部出力をそのままシェル実行しない」境界を仕組みで設ける |
| 認証情報の隔離 | .env をローカルに置かず、クラウドシークレット管理へ |
4月の記事で書いたフルバックのメタファーを覚えているでしょうか。スキャンやアップデートは前方のディフェンスライン、Zen は最後尾でピッチ全体をカバーするフルバック——あの三層防御モデルは、まさに「前線が抜かれる前提」で最後尾を置く設計でした。Agentjacking は、その「前線(=エージェント個人の判断)は抜かれる」という前提が正しかったことを証明したわけです。
Agentjacking が突きつけたのは、シンプルな事実です。
人間を騙すのではなく、エージェントの信頼経路を騙す時代になった。
EDRもWAFもIAMも、この攻撃をすり抜けます。チェーンのすべての動作が「正規に認可された」操作だからです。検知すべき「悪いもの」が、どこにも無い。
だからこそ、防御の発想を切り替える必要があります。
エージェント時代の防御は、監視ではなく設計。 プレイヤーが抜かれることを前提に、ディフェンスシステムを組む。
「抜かれない壁」を追いかけるのをやめて、「抜かれても破綻しない構造」を作る。それが、AIエージェントを業務に組み込むすべての組織の、次の宿題です。
参考:
Aikido Community Japan
公開日: 2026/6/12
最終更新: 2026/6/13
セキュリティの最新情報をお届けします。