AIコーディングエージェントの構造的セキュリティリスクとは、特定ツールのバグではなく、「永続的な認証情報を持つ AI が攻撃者の到達可能なテキストを読む」というアーキテクチャ自体に内在する脆弱性です。2026年上半期、GitHub Copilot・Claude Code・Cursor・Amazon Q の主要4ツールすべてで共通の設計課題に起因するインシデントが発覚しました。本記事では8件のインシデントを横串で分析し、構造的リスクの判断フレームワークとツール別の対策チェックリストを提示します。

あなたの AI エージェントは、攻撃者の Issue を素直に読んでいるかもしれない

チームに GitHub Copilot を導入して数ヶ月。Issue の自動対応やコードレビューの効率化が軌道に乗り始めた頃、こんなニュースが飛び込んできます。

2026年7月6日、セキュリティ企業 Noma Security が「GitLost」と題する脆弱性を公開しました。攻撃者がパブリックリポジトリの Issue に数行の英文テキストを投稿するだけで、GitHub の AI エージェントが組織内のプライベートリポジトリの内容を読み取り、パブリックなコメントとして投稿してしまいます。GitHub はコンテナ分離や Secret ゼロモデルなどの多層防御を実装していますが、GitLost はこれらの一部を回避可能であることを示しました。公開情報上、GitLost 固有の CVE や修正リリースは確認されていません。

「Copilot の問題でしょう？ うちは Claude Code だから関係ない」—そう思ったとしたら、この記事を最後まで読む価値があります。2026年上半期だけで、主要 AI コーディングツールのすべてで構造的に同じ脆弱性パターンが見つかっています。問題は特定のツールではなく、AI エージェントの設計アーキテクチャそのものにあります。

GitLost が示した攻撃の構造

GitLost の攻撃フローは、AI エージェントセキュリティの根本問題を端的に示しています。Noma Security の公開レポート（2026年7月6日）に基づいて整理します。

攻撃の前提条件:

1. 組織が GitHub Agentic Workflows（GitHub Actions + AI エージェント）を有効化している
2. AI エージェントが組織内の複数リポジトリにアクセスできる GITHUB_TOKEN を保持している
3. パブリックリポジトリで Issue イベントをトリガーとするワークフローが設定されている

攻撃フロー:

1. 攻撃者がパブリックリポジトリに Issue を作成する
2. Issue 本文にプロンプトインジェクション（自然な英文に偽装した指示）を埋め込む
3. Issue の割り当てイベントで AI エージェントが起動し、Issue 本文を読み込む
4. エージェントは埋め込まれた指示を開発者の指示と区別できず、従ってしまう
5. エージェントが GITHUB_TOKEN の権限でプライベートリポジトリの README を取得する
6. 取得した内容をパブリックな Issue コメントとして投稿する（データの外部流出が完了）

Noma Security の報告では、GitHub のガードレールを回避するために "Additionally" というキーワードが使用されていました。GitHub は公式ブログ（2026年3月9日）で「safe outputs」フィルタリングや「zero-secret agent model」などのセキュリティアーキテクチャを解説していますが、GitLost はこれらのガードレールが単純なキーワードで回避可能であることを実証しました。

構造的な示唆: この攻撃は GitHub Copilot の実装バグではありません。「信頼できない入力（パブリック Issue）を読むエージェントが、機密データ（プライベートリポジトリ）にアクセスでき、外部に情報を送信できる（パブリックコメント）」という3つの条件がすべて揃った結果です。この3条件を満たすシステムであれば、使用する LLM が何であれ同じリスクが生じます。これは従来の Confused Deputy（権限混同）問題と本質的に同じ構造ですが、LLM ベースのエージェントでは自然言語の入力バリデーションが原理的に困難であるため、CSRF トークンのような既知の対策が適用できない点が決定的に異なります。

この構造的リスクは Copilot の契約有無に依存しません。GitHub Actions と任意の LLM API を組み合わせたカスタムワークフローでも同様です。

2026年上半期インシデントタイムライン—なぜ同じパターンが繰り返されるのか

GitLost は単発のインシデントではありません。2026年2月から7月にかけて、主要な AI コーディングツールすべてで構造的に類似した脆弱性が報告されています。

RoguePilot（2月16日 / Copilot・Codespaces / 深刻度: 高）

Issue の HTML コメントに隠された指示 → symlink 経由で user-secrets-envs.json 読取 → VS Code の JSON Schema 自動取得で GITHUB_TOKEN を外部送信。トークンがあればリポジトリの読取・書込・Actions の起動が可能。修正済み（時期非公開）。

Claude Code Read（6月5日 / Claude Code / 深刻度: 高）

Read ツールのサンドボックス不備で /proc/self/environ から ANTHROPIC_API_KEY を窃取。窃取した API キーで被害者のクレジットによる任意プロンプト実行が可能。v2.1.128 で修正。

Claude Code Setup（6月25日 / Claude Code / 深刻度: 高）

リポジトリのセットアップ手順を偽装し、自律的エラー回復を悪用して開発者権限のシェルを奪取。ローカルファイル全体の読取・改竄、SSH 鍵やクラウド認証情報の窃取が可能。公開情報上、修正未確認。

Amazon Q MCP（6月26日 / Amazon Q / CVE-2026-12957）

.amazonq/mcp.json のユーザー同意なし自動読込 → AWS 認証情報を含む全環境変数を継承。継承された IAM 権限次第で S3・Lambda・DynamoDB 等の AWS リソースに無制限アクセスが可能。language server 1.65.0 で修正。

Miasma Worm（6月5日発生・6月30日公開 / Claude Code, Cursor, Gemini CLI, VS Code / 深刻度: 緊急）

AI ツール設定ファイル（SessionStart hook / alwaysApply rules / folderOpen task）にペイロード注入する自己複製型ワーム。感染リポジトリを clone した全開発者に連鎖感染し、各端末の認証情報・ソースコードが漏洩する。Microsoft の73リポジトリが侵害された後、GitHub の自動 ban が105秒で全リポジトリを凍結。GitHub が対象リポジトリを無効化。

DuneSlide（7月1日 / Cursor / CVSS 9.8: CVE-2026-50548, CVE-2026-50549）

MCP 経由のプロンプトインジェクション → 作業ディレクトリ操作と symlink の正規化不備で RCE。ゼロクリック攻撃。攻撃者のコードが開発者権限で実行され、ローカルの SSH 鍵・認証情報・ソースコード全体にアクセス可能。公開（7月1日）前に段階的に修正（CVE-2026-50548 は Cursor 3.0／4月2日、CVE-2026-50549 は6月1日）。

GitLost（7月6日 / GitHub Agentic Workflows / 深刻度: 高）

Issue 本文のプロンプトインジェクション → プライベートリポジトリ読取 → パブリックコメントで漏洩。非公開のソースコード、シークレット、内部ドキュメントが第三者に公開される。公開情報上、CVE・修正リリース未確認。

GhostApproval（7月8日 / Amazon Q, Claude Code, Cursor, Augment, Windsurf, Google Antigravity / 高: CVE-2026-12958 等）

symlink で UI 表示と実際の操作先を不一致に（CWE-61 + CWE-451）→ ~/.ssh/authorized_keys 等を上書き。攻撃者が被害者マシンに SSH ログイン可能になり、永続的なバックドアとして機能する。Amazon Q, Cursor, Google は修正済み。Claude Code は当初脅威モデル外と判断したが後に緩和策を追加。Augment, Windsurf は対応中。

5ヶ月間で8件。深刻度は CVSS 9.8 の RCE から CVE 未発行のものまで幅がありますが、対象ツールは GitHub Copilot、Claude Code、Cursor、Amazon Q、Gemini CLI、Windsurf、Augment と、市場の主要プレイヤーを網羅しています。なお、DuneSlide と GhostApproval はいずれも Cursor の symlink 処理を攻撃面としており、CVE-2026-50549 を共有しています（同一の根本原因に起因）。

これらはすべて同一の脆弱性ではありません。プロンプトインジェクション（GitLost, RoguePilot）、サンドボックスバイパス（DuneSlide, Claude Code Read）、設定ファイルの信頼境界崩壊（Amazon Q, Miasma Worm）、symlink による UI 偽装（GhostApproval）と、攻撃手法は異なります。しかし、共通しているのは 「AI エージェントが、従来は信頼境界の外にあった入力・設定・ファイルを、操作可能な命令として扱ってしまう」 点です。

個別のパッチで対処しても、同じ構造的条件が揃えば新たな脆弱性が見つかり続ける—これが2026年上半期のデータが示す現実です。

共通する構造—「致命的三条件」

セキュリティ研究者 Simon Willison は、このパターンを「Lethal Trifecta（致命的三条件）」と名付けました。以下の3つの能力がすべて揃ったシステムでは、個別パッチでは根本的に防ぎきれないという主張です。

条件	定義
A. 機密データへのアクセス	エージェントが非公開の情報を読める
B. 信頼できないコンテンツの処理	攻撃者が到達可能なテキストをエージェントが読む
C. 外部への通信能力	エージェントが外部にデータを送信できる

Lethal Trifecta の核心は、LLM が入力テキストの「出所」を区別できないという技術的制約にあります。開発者が書いたシステムプロンプトも、攻撃者が Issue に埋め込んだ指示も、モデルにとっては等しく「テキスト」です。3条件がすべて揃うと、攻撃者は条件 B を通じて指示を注入し、条件 A で機密情報を取得させ、条件 C で外部に送信させることができます。

2026年の8件のインシデントをこのフレームワークで分類すると、パターンが浮かび上がります。

インシデント	A: 機密データ	B: 信頼できない入力	C: 外部への影響
RoguePilot	secrets, GITHUB_TOKEN	Issue HTML コメント	VS Code schema 取得
Claude Code Read	API キー, /proc	リポジトリコンテンツ	ツール実行
Claude Code Setup ※	開発者権限のシェル	リポジトリのセットアップ手順	シェルコマンド実行
Amazon Q	AWS 認証情報, 環境変数	ワークスペース MCP 設定	プロセス生成
Miasma Worm	OIDC トークン, 認証情報	設定ファイル	npm 公開, コミット
DuneSlide	ファイルシステム全体	MCP / Web コンテンツ	任意コード実行
GitLost	プライベートリポジトリ	パブリック Issue	パブリックコメント
GhostApproval	システムファイル (.ssh)	リポジトリ symlink	ファイル書込み

GitLost と RoguePilot は、条件 B → A → C の流れで機密データが外部に到達する典型的な Lethal Trifecta パターンです。Claude Code Read も同様の流れですが、C の経路がツール実行です。DuneSlide（RCE）、Amazon Q・Miasma Worm（設定ファイル自動読込）、GhostApproval（symlink traversal）は、C 列の性質がデータ流出ではなく任意コード実行やファイル改ざんであり、Willison の元の定義より広い範囲に該当します。※ Claude Code Setup はソーシャルエンジニアリングと自律的エラー回復の悪用であり、典型的な Lethal Trifecta パターンには該当しません。

攻撃の性質に差はありますが、いずれも「AI エージェントのデフォルト構成が、意図せず広い権限を同時に保持している」という共通の設計課題を反映しています。

まず確認すべき3問

以下はリスクのスクリーニング（ふるい分け）です。チームの Slack にそのまま貼れる形で整理します。

1. AI エージェントは、パブリックな Issue・PR・Web コンテンツを読んでいるか？（条件 B: 信頼できない入力）
2. そのエージェントの実行権限で、プライベートリポジトリ・secrets・クラウド認証情報に到達できるか？（条件 A: 機密データ）
3. コメント投稿・ファイル書込み・外部通信が、ユーザー承認なしに自動実行されるか？（条件 C: 外部通信）

3つすべてに「はい」と答えた場合、そのエージェントは致命的三条件を満たしています。最低でも1つを「いいえ」に変えてください。なお、各条件のリスクはアクセス範囲の広さや通信先の制御可能性によって異なります。「はい」の内容が具体的にどの程度かを評価するには、後述のツール別チェックリストを参照してください。

Agents Rule of Two—「3つのうち2つまで」の設計原則

Lethal Trifecta が「なぜ危険か」を説明するフレームワークなら、Meta が2025年10月に提唱した「Agents Rule of Two」は「どう設計すべきか」を示す設計原則です。

エージェントは、セッション内で以下の3つの性質のうち最大2つまでしか同時に満たしてはならない—プロンプトインジェクションの最も深刻な影響を回避するために。
— Meta AI, "Practical AI Agent Security" (2025年10月31日) より意訳

Lethal Trifecta と同じ A/B/C のラベルで整理します。

性質	定義
[A] 機密システム・データへのアクセス	非公開リポジトリ、認証情報、内部 API などにアクセスできる
[B] 信頼できない入力の処理	ユーザー投稿、外部コンテンツなど、攻撃者が制御可能なデータを読む
[C] 状態の変更・外部通信	ファイルの書込み、コメントの投稿、ネットワーク通信を行える

Meta は3つの安全な構成パターンを提示しています。

構成	許可する性質	除外する性質	実装例
[AB]	機密データ + 信頼できない入力	外部通信を禁止	CI の自動コードレビュー（結果は PR 内部コメントのみ、外部 Webhook なし）
[AC]	機密データ + 外部通信	信頼できない入力を遮断	プライベートリポジトリの定期セキュリティスキャン（cron トリガー、外部入力なし）
[BC]	信頼できない入力 + 外部通信	機密データを遮断	公開リポジトリの Issue トリアージ（ラベル付与・定型応答のみ、secrets 参照なし）

この原則は Microsoft Security Blog でも「Securing CI/CD in Agentic World」（2026年6月5日）として、CI/CD パイプラインへの適用が解説されています。

注意すべき点が2つあります。第一に、Rule of Two はプロンプトインジェクション自体を防ぐものではありません。現時点では、LLM がプロンプトインジェクションを100%検出・拒否する技術は存在しません。Rule of Two は「インジェクションが成功しても、3条件が揃わないため致命的な被害に至らない」ように設計する原則です。

第二に、原文の "within a session"（セッション内で）という限定が重要です。同じエージェントでも、処理フェーズごとにセッションを分離すれば、各セッション内では2条件に収めることができます。たとえば、Issue の内容を読み取るセッション（A + B、外部通信なし）と、分析結果をもとに応答コメントを投稿するセッション（B + C、機密データへのアクセスなし）に分けることで、全体としては3条件を使いつつ各セッションでは Rule of Two を満たせます。GitHub Actions での実装例を示します。

jobs:
  analyze:  # セッション1: [A+B] プライベートコードを参照し、Issue を読む
    permissions:
      contents: read    # GITHUB_TOKEN のスコープ制御（条件 A）
      issues: read
    steps:
      - run: "分析結果をアーティファクトに出力"

  respond:  # セッション2: [B+C] 分析結果をもとに応答
    needs: analyze
    permissions:
      issues: write
      # contents 権限なし＝条件 A を除外
    steps:
      - run: "アーティファクトの結果をもとにコメントを投稿"

jobs を分離することで、各ジョブの GITHUB_TOKEN スコープを独立に制御できます。respond は contents 権限を持たないため、プライベートリポジトリのコードに直接アクセスできません（条件 A の除外）。

重要な注意: permissions は GITHUB_TOKEN のスコープ（条件 A: どの機密データにアクセスできるか）を制御するものであり、ランナーのネットワーク通信（条件 C）は制限しません。analyze ジョブでも curl 等で外部サーバーにデータを送信することは可能です。条件 C を設計レベルで断つには、ネットワークエグレス制限やエージェントへのツール制限など、別レイヤーの制御が必要です。

また、アーティファクト経由で機密データが respond に渡る場合は条件 A が実質的に漏れ出します。analyze の出力は判定結果（ラベル名、優先度等）に限定し、ソースコードや secrets を含めないようにしてください。

ツール別ハードニングチェックリスト

「まず確認すべき3問」で課題が見つかった方向けに、具体的な設定項目をツールごとにまとめます。Rule of Two の構成パターンを実際の設定に落とし込んだものです。

ワークスペース由来の設定ファイルは「攻撃者入力」と見なす

2026年上半期のインシデントで繰り返し悪用されたのが、リポジトリに含まれる設定ファイルの自動読込です。.amazonq/mcp.json（Amazon Q）、.cursor/mcp.json（Cursor）、.claude/settings.json（Claude Code）、.github/setup.js（Miasma Worm）—これらはすべて、リポジトリの clone と同時にエージェントが信頼して読み込むファイルです。

信頼できないリポジトリを clone した時点で、そこに含まれる設定ファイルは攻撃者の入力と同等です。AI エージェントでリポジトリを開く前に、これらの設定ファイルの内容を目視確認する習慣をつけてください。

GitHub Copilot / Agentic Workflows

GitHub Agentic Workflows は組織レベルでの制御が重要です。

チェック項目	対応する条件	推奨設定
Agentic Workflows の有効範囲	A（機密データ）	組織全体ではなくリポジトリ単位で有効化する
GITHUB_TOKEN の権限	A（機密データ）	permissions で必要最小限のスコープに制限する（下記の例を参照）
Issue トリガーの対象	B（信頼できない入力）	パブリックリポジトリでの Issue トリガーを無効化、または信頼されたメンバーの Issue のみに制限する
copilot-instructions.md	B（信頼できない入力）	セキュリティポリシーを記載する（GitLost が示すようにガードレール回避は可能。多層防御の一要素として位置づける）

permissions の最小化例（GitHub Actions ワークフロー定義）:

permissions:
  contents: read    # リポジトリ内容の読取のみ
  issues: write     # Issue コメントの投稿に必要
  # pull-requests, packages, actions 等は明示的に付与しない

参考: GitHub Agentic Workflows Security Architecture（2026年3月9日）

Claude Code

Claude Code はファイルレベルの権限制御が可能です。

チェック項目	対応する条件	推奨設定
許可ツールの制限	C（外部通信）	.claude/settings.json の permissions.allow を明示的に列挙し、不要なツールを除外する（下記の例を参照）
信頼できないリポジトリ	B（信頼できない入力）	未知のリポジトリを clone して即座に実行しない。Mozilla 0DIN の報告では、セットアップ手順に偽装した指示で開発者権限のシェルが奪取された
MCP サーバーの管理	B + C	信頼できる MCP サーバーのみを設定に追加する。ワークスペース由来の MCP 設定を自動読込しない
パーミッションプロンプト	C（外部通信）	外部通信を伴うツール実行前の確認プロンプトを無効化しない

permissions の制限例（.claude/settings.json）:

{
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Write",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(npm test)",
      "Bash(npm run lint)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(git push *)"
    ]
  }
}

allow で許可するツールを明示し、deny で意図しないコマンドを制限します。Bash(git *) のようなワイルドカードは git push も許可してしまうため、必要なサブコマンドを個別に列挙してください。

重要な注意: deny ルールはセキュリティ境界ではありません。Bash(curl *) を遮断しても、Python や Node.js スクリプト経由の HTTP 通信は制限されません。条件 C を設計レベルで断つには、サンドボックス環境での実行やネットワーク分離が必要です。allow/deny は多層防御の一要素として位置づけてください。設定の最新仕様は公式ドキュメントを確認してください。

参考: Claude Code Security - Anthropic

Cursor

Cursor は DuneSlide（CVSS 9.8）を受けてバージョン3.0でサンドボックス機能を強化しています。

チェック項目	対応する条件	推奨設定
バージョン確認	全体	Cursor 3.0 以上を使用する（DuneSlide の2件の RCE 修正を含む）
MCP サーバー設定	B + C	.cursor/mcp.json に信頼できるサーバーのみを登録する。不明なリポジトリからの MCP 設定自動読込を無効化する
プロジェクトルール	B（信頼できない入力）	.cursor/rules でセキュリティポリシーを定義する（ガードレール回避の可能性を認識した上で、多層防御として使用する）
ワークスペース信頼	A + B	信頼できないソースからクローンしたプロジェクトは、制限モードで開く

参考: Cursor Security

全ツール共通

チェック項目	根拠
CI/CD パイプラインの認証情報を最小権限にする	Lethal Trifecta: 条件 A の攻撃面を最小化
AI エージェントの操作ログを監視し、異常な外部通信を検知する	CSA Confused Deputy（2026年3月）: 行動レベルの異常検知を推奨
AI プラグイン・MCP サーバーをサプライチェーンリスクとして管理する	OWASP ASI Top 10: ASI-03 Identity & Privilege Abuse

政策・学術からの裏付け

ここまで見てきた構造的リスクの認識は、セキュリティ研究者だけでなく、国家機関や学術界にも広がっています。

Five Eyes 共同ガイダンス（2026年5月1日）: 米国 CISA・NSA、英国 NCSC、豪州 ASD、カナダ CCCS、NZ NCSC の5カ国6機関が「Careful Adoption of Agentic AI Services」を共同発行し、100以上の推奨事項を示しました。報道によれば、Five Eyes が単一の AI 攻撃面について共同ガイダンスを出すのはこれが初めてとされています。

University of Warwick / アラン・チューリング研究所（2026年7月）: 「Refused in Chat, Written in Code」では、GitHub Copilot 上で4つの LLM（Claude Sonnet 4.6、Claude Haiku 4.5、Gemini 3.1 Pro、Gemini 3.5 Flash）に204の有害プロンプトを投入（計816試行）。チャットでの直接指示では大半が拒否されましたが、有害な指示をソフトウェア開発ワークフローの複数ステップに分散させる（各ステップ単体では無害に見える形に分割する）と、816試行中すべてでガードレールが迂回されました。

CSA Confused Deputy（2026年3月）: Cloud Security Alliance が「AI Agent Confused Deputy」で4段階の攻撃チェーンを定義し、行動レベルの異常検知を推奨しています。

これらが示しているのは、AI エージェントの構造的なセキュリティ課題—ガードレールの限界と権限設計の問題—が、国際的なセキュリティコミュニティで共有認識になっているということです。

構造的リスクとの付き合い方

AI コーディングエージェントの全面禁止は、多くのチームにとって現実的ではありません。求められるのは、用途別に権限を分離して生産性とセキュリティを両立させる運用です。

2026年上半期のインシデントが示しているのは、Lethal Trifecta の3条件がすべて揃った状態で AI エージェントを運用することの危険性です。Rule of Two に従い、エージェントの用途ごとに「どの条件を断つか」を決めることがリスク低減の鍵になります。

• 条件 B を遮断する: パブリックリポジトリの Issue やプルリクエストで AI エージェントをトリガーしない
• 条件 A を制限する: AI エージェントの GITHUB_TOKEN 権限を、操作対象のリポジトリのみに限定する
• 条件 C を制限する: AI エージェントの外部通信（コメント投稿、ファイル書込み、ネットワーク通信）を承認制にする
• 3条件がすべて必要な場合: 自律実行を停止し、各アクションに human-in-the-loop（人間の承認）を挟む

高規制業界（金融、医療、防衛等）では、AI エージェントの利用自体を制限する判断も当然あり得ます。

完全な防御は存在しません。しかし、構造を理解した上で運用することと、リスクを知らずに使い続けることの間には大きな差があります。セキュリティや AI・機械学習の動向を追いつつ、本記事の「まず確認すべき3問」とチェックリストをチームのセキュリティレビューの起点として活用してください。

参考文献

• GitLost: How We Tricked GitHub's AI Agent Into Leaking Private Repos - Noma Security（2026年7月6日）
• The Lethal Trifecta - Simon Willison（2025年6月16日）
• Practical AI Agent Security - Meta AI（2025年10月31日）
• OWASP Top 10 for Agentic Applications（2026年）
• Careful Adoption of Agentic AI Services - CISA / Five Eyes（2026年5月1日）
• Refused in Chat, Written in Code - University of Warwick / Alan Turing Institute（2026年7月）
• Under the Hood: Security Architecture of GitHub Agentic Workflows - GitHub（2026年3月9日）
• Securing CI/CD in Agentic World - Microsoft Security Blog（2026年6月5日）
• AI Agent Confused Deputy - Cloud Security Alliance（2026年3月23日）