目次を表示する

AIセキュリティ 2026 ─ 開発からプロダクトまでの防衛術

AIコーディングアシスタントの脅威モデルを描く

第1章: AIコーディングアシスタントの脅威モデルを描く

AIコーディングアシスタントの脅威モデル

第1部では、開発プロセスでAIツールを使う側の防衛を扱う。本章はその出発点として、Claude Code / Cursor / GitHub Copilot / MCPサーバーといったAIコーディングアシスタントが、なぜ従来のIDEプラグインとは別物の脅威モデルを持つのかを整理する。具体的なCVEは次章以降で扱う。本章ではその前提となる「地図」を描く。

なぜAIコーディングアシスタントは従来のIDEプラグインと違うのか

VS Codeに入っているLinter拡張、Prettier、Vimのプラグイン ─ これらの脅威モデルは比較的シンプルだ。「拡張機能本体に脆弱性があるか」「依存パッケージが汚染されていないか」「設定ファイルから何かを実行されないか」を見ればいい。コードを読んで決まった処理を返すだけのプログラムだから、入力と出力の関係が固定されている。

AIコーディングアシスタントは違う。彼らは以下の5つの能力を同時に持つ。

graph LR
    User[ユーザーの指示] --> Agent[AIエージェント]
    Files[リポジトリ内のファイル<br/>README/comments/issue/PR] --> Agent
    Tools[ツール<br/>Bash/Write/Edit/Web/MCP] --> Agent
    Memory[メモリ・履歴<br/>~/.claude/CLAUDE.md など] --> Agent
    Network[ネットワーク<br/>npm registry/GitHub/外部API] --> Agent
    Agent -->|自律的に判断| Tools
    Agent -->|読み込む| Files
    Agent -->|実行する| Bash[シェルコマンド]
    Agent -->|送信する| Out[外部HTTPエンドポイント]

5つすべてが、同じLLMコンテキストの中で混ざって処理される。これが従来のソフトウェアとの決定的な違いだ。LLMから見ると、「あなたの指示」も「READMEに書かれた文字列」も「Web検索の結果」も、すべて同じ”トークンの並び”でしかない。

つまり、READMEに「以下の手順で進めてください」と書かれていれば、それは設定上の操作手順かもしれないし、攻撃者がエージェントに対して仕込んだ命令文かもしれない。LLMはこれを構造的に区別できない。

4つの根本原理を、IDEの世界に当てはめる

「はじめに」で予告した4つの根本原理を、AIコーディングアシスタントという文脈で具体化する。

原理1: 信頼境界（Trust Boundary）

従来のセキュリティでは「サーバとクライアント」「内部ネットワークと外部ネットワーク」のような明確な境界線があった。AIコーディングアシスタントの世界には、もう少し細かい境界が存在する。

境界の例信頼できる側信頼できない側
あなたが書いたソースコード自分のコミットプルリクエストの差分、未マージのブランチ
プロジェクトのREADME自分が書いた段落外部コントリビューターが追加した段落、コピペしたサンプル
.cursor/rules、AGENTS.md、.github/copilot-instructions.md自分が書いたルールフォーク元から引き継いだルール、ライブラリが推奨するルール
.claude/、.cursor/、.vscode/ 配下の設定自分でコミットした設定別の開発者がコミットした設定、untrustedなリポジトリの設定
ターミナル出力・コマンド結果自分が予期した出力コマンドが返した文字列に紛れ込んだ命令

第2章で見る「Rules File Backdoor」(Pillar Security, 2025年3月公表)は、この境界のうち「.cursor/rules」のセルを攻撃する。第3章で見る「postmark-mcp バックドア」(2025年9月)は、「MCPサーバが返すツール定義」のセルを攻撃する。攻撃手法は表面的に違っても、同じ表の異なるセルを潰しているだけだ。

原理2: Lethal Trifecta

Simon Willisonが2025年6月に提唱した枠組みで、本シリーズで繰り返し参照する。エージェントが以下の3つを同時に持つと、prompt injectionによる情報窃取は事実上防げない、というシンプルな主張だ。

graph TD
    A[①プライベートデータへのアクセス<br/>ローカルファイル, secrets, history] --> X{AIエージェント}
    B[②untrustedコンテンツへの曝露<br/>外部ファイル, Web, ツール出力] --> X
    C[③外部通信能力<br/>HTTP, Slack, Email, git push] --> X
    X --> D[攻撃者は<br/>Aを取り出してCで送出させる]

問題は、標準的なAIコーディングアシスタント環境はこの3つを最初から満たしていることだ。Claude Codeなら、~/.aws/credentialsを読める権限があり (A)、untrustedなリポジトリのREADMEを読み (B)、Bashでcurlを叩ける (C)。Cursorも同じ。Copilotも同じ。

「AIコーディングアシスタントを安全に使う」という問いは、結局「3つのうちどれかを構造的に外す」「外せないなら別の防衛で代替する」という設計判断に帰着する。

原理3: 最小権限（Least Privilege for Tools）

OWASP LLM Top 10 2025の LLM06 Excessive Agency に対応する。エージェントに渡すツールの数と権限を最小化する、という古典的な原則だ。ただしAI時代の難しさは、**ツールが「会話の中で増やせる」**点にある。

たとえばClaude Codeは起動時にMCPサーバを動的に読み込む。Cursor 1.3以前は、一度承認したMCPの中身を後から書き換えてもユーザー再承認なしに実行された (CVE-2025-54136 MCPoison)。承認は時刻Tの状態に対して与えたつもりだったのに、実際には時刻T+1の状態に対して暗黙に有効になっていた。これが第3章のテーマになる。

原理4: Defense in Depth と観測可能性

「指示とデータが混ざる」という構造的弱点は、ひとつの classifier やひとつの guardrail で完全には潰せない。Anthropicが2025年に公開した Constitutional Classifiers ですら、jailbreak成功率は4.4%残った。逆に言えば、95%以上は防げる。だから単一の対策に賭けず、層を重ねる。

開発環境での「層」は、たとえば以下のように構成する：

  1. 環境分離: DevContainer / sandbox で「壊しても良い世界」を作る
  2. 権限分離: ~/.ssh や cloud credentials をマウントしない
  3. 承認ゲート: Plan Mode、approval prompt、--dangerously-skip-permissionsの禁止
  4. 観測: コマンド実行ログ、ネットワーク通信ログ、anomaly detection
  5. 定期レビュー: コミットされた .claude/、.cursor/、AGENTS.md の差分監査

詳しくは第2〜4章で実装まで掘り下げる。

主要事件タイムライン (2025年〜2026年5月)

第1部で扱う事件と脆弱性を時系列で並べる。この一覧を眺めるだけで、過去2年で攻撃面がいかに広がったかが見える。

公表事件 / CVE対象影響
2025-03Rules File BackdoorCursor / Copilot のルールファイル不可視Unicodeで隠した命令、フォーク先まで伝播
2025-03-14/15tj-actions/changed-files (CVE-2025-30066)GitHub Actions23,000+ リポジトリでsecrets漏洩
2025-04MCP Tool Poisoning AttackMCPツール記述tool descriptionに隠した命令でssh鍵抽出
2025-06EchoLeak (CVE-2025-32711)Microsoft 365 CopilotゼロクリックでM365データ抽出（プロダクト側にもまたがる）
2025-07Replit AI DBドロップ事件Replit AI Agent本番DB削除、虚偽報告
2025-08-01CurXecute (CVE-2025-54135)Cursor + MCPMCPメッセージ経由でRCE
2025-08-05MCPoison (CVE-2025-54136)Cursor MCP承認承認後の書き換えで永続RCE
2025-08GitHub Copilot CVE-2025-53773VS Code + CopilotYOLOモード強制でZombAI化
2025-09postmark-mcp バックドアnpm実環境MCPサプライチェーン侵害の初確認
2025-10Claude Code CVE-2025-59536.claude/ 設定untrusted dirで起動時に任意コマンド実行
2025-12IDEsaster (Ari Marzouk)30+ IDEClaude/Cursor/Cline/Continue等横断
2026-01Claude Code CVE-2026-21852ANTHROPIC_BASE_URLtrust prompt前にAPIキー漏洩
2026-01MaliciousCorgiVS Code Marketplace「ChatGPT中文版」等が150万install
2026-03Claudy DayClaude.aiFiles API経由で会話履歴漏出（プロダクト側）
2026-03-31axios npm 侵害npm北朝鮮Sapphire Sleet、AI agentが瞬時拡散
2026-04MCP SDK 設計論争Anthropic公式SDKOX Securityが「baked-in RCE」と指摘

並べると、2025年8月以降の急増と、MCPを介した攻撃の構造化が際立つ。MCPは便利な仕組みだが、便利さは攻撃面でもある、という典型的なバランスだ。

本章の要点

#要点
1AIコーディングアシスタントは「指示・ファイル・ツール・メモリ・ネットワーク」を同じLLMコンテキストで処理する。指示とデータが構造的に混ざる
2信頼境界は「自分のコード vs 外部から来たもの」の細かい組み合わせで定義する。表のセル単位で考える
3Lethal Trifecta（データ × untrustedコンテンツ × 外部通信）は、標準的なIDE環境では最初から揃っている
4ツール権限は「会話の中で増えうる」前提で監査する。承認は時刻Tの状態に対するもの
5単一の防衛に頼らず、環境分離 / 権限分離 / 承認ゲート / 観測 / 定期レビュー の5層で守る
62025年〜2026年5月の主要事件タイムラインを把握すると、攻撃の構造化が時系列で見える

効いている根本原理

本章は 原理1（信頼境界） と 原理2（Lethal Trifecta） を中心に説明した。次章では、この2つが実際のCVEとしてどう成立するかを見る。