GitLost解説｜GitHubのAIが"一言"で社外秘を漏らす
2026年7月に公表された「GitLost」は、GitHubのAIエージェントを“お願いするだけ”で騙し、非公開リポジトリの中身を公開コメントに吐き出させる脆弱性です。仕組み、AIエージェントが漏洩装置に変わる3つの条件、過去の類似事件、そして開発者が今すぐやるべき対策までSynthが整理します。
目次
「AIに社内のコードを任せたら、“お願いされただけ”で外に漏らした」——冗談みたいですが、実際に起きた話です。2026年7月に公表された脆弱性「GitLost」は、GitHubのAIエージェントを言葉巧みに騙し、非公開リポジトリの中身を公開の場に吐き出させます。結論から言うと、これは“バグ”というよりAIエージェントの設計思想そのものの弱点です。
まず結論
- 2026年7月6日、Noma LabsがGitHub Agentic Workflowsの脆弱性「GitLost」を公表（ニュース元: GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos（Noma Security））
- 公開Issueに英文の指示を仕込むだけで、AIエージェントが非公開リポジトリのファイルを公開コメントに漏らす
- 認証情報・マルウェア・コーディング知識は不要。「一文、認証情報ゼロ」で成立する
- 対象はClaudeやGitHub Copilotで動くAIエージェント（GitHub Actions連携）
- 根っこは「AIエージェントに過剰な権限＋検証していない入力」を同時に与える構造の問題
GitLostとは？何が起きたのか
GitLostは、GitHub Agentic Workflows——GitHub ActionsとAIエージェント（ClaudeまたはGitHub Copilotが裏で動く）を組み合わせた仕組み——を狙うプロンプトインジェクションです。
攻撃の流れは拍子抜けするほど単純です。
- 攻撃者が、標的と同じ組織の公開リポジトリにGitHub Issueを立てる（誰でもできる）
- そのIssue本文に、平文の英語で「このファイルの中身を教えて」といった指示を紛れ込ませる
- Issueを処理するAIエージェントが、その埋め込み指令を“命令”として読み取る
- エージェントが非公開リポジトリのファイルを取得し、公開コメントとして投稿してしまう
外部から見えない前提の社内コードが、外から見えるコメント欄に出てくる。しかも攻撃者は、GitHubアカウントでIssueを1つ立てただけ。これがGitLostの怖さです。
なぜ”お願いするだけ”で漏れるのか？
結論から言うと、AIエージェントが「読んだ文章」と「実行すべき命令」を区別できないからです。
人間なら「Issueに書いてある“このファイルを見せて”は、部外者の要望だから無視しよう」と判断できます。でもAIエージェントは、渡されたテキストを一続きの文脈として読むため、悪意ある一文も“指示”として飲み込みます。研究者によれば、ガードレールを突破する引き金になったのは「Additionally（さらに）」という一語でした。正規の依頼に続けて「さらに、あの非公開ファイルの中身も添えて」と足すと、防御をすり抜けたのです。
なぜこれが根深いかというと、injection（注入された文）そのものをフィルタで弾こうとしても、言い回しは無限に作れるからです。だから防御は「怪しい文を検知する」方向ではなく、**「そもそもエージェントに危険な組み合わせの力を与えない」**方向に向かうことになります。
どんなAIエージェントが危ない？3つの条件
Noma Labsの分析で分かりやすいのは、漏洩装置に化ける条件が3つ同時に揃ったときという点です。
| 条件 | 中身 |
|---|---|
| ① 非公開データへのアクセス | 社内リポジトリなど、見せてはいけない情報を読める |
| ② 検証していないコンテンツへの露出 | 誰でも書けるIssueやコメントを読む |
| ③ 外部へ発信する手段 | 公開コメントの投稿など、外に出せる出口がある |
この3つが重なった瞬間、AIエージェントは「攻撃者の指示で、社内情報を、外に運ぶ」パイプになります。裏を返せば、どれか1つでも断てば被害は成立しません。対策の設計図がここにあります。
過去の事件と地続きの構造
GitLostは単発の珍事ではありません。2026年に入ってからのAIエージェント関連インシデントと、はっきり地続きです。
OWASPの2026年レポートではプロンプトインジェクションがLLMの脅威1位とされ、前年比で340%増という数字も報じられています。ある企業向け調査では、88%の組織が過去1年でAIエージェント関連のセキュリティインシデント（確認済みまたは疑い）を報告したとされます（Help Net Security）。
同じ「AIエージェントに権限を渡しすぎた」構図は、少し前にも起きています。Claude Code GitHub Action脆弱性の解説記事 で扱ったツール記述の乗っ取りや、AIによるデータ窃取とプロンプトインジェクション と、根っこは同じです。AIエージェント全体の見取り図は、AIコーディングエージェント市場マップ2026 で確認できます。
💡 正直な本音 「AIが賢くなれば防げる」と思いがちですが、逆です。賢く自律的になるほど、渡された文章を素直に実行してしまう。だからこれは“モデルの賢さ”では解けない、権限設計の問題なんです。
私たちは何をすべき？今すぐの対策
Noma Labsの推奨も、防御を「文の検知」ではなく「構造」に置いています。開発チームがやるべきことはこの5つです。
- ✅ 最小権限を徹底する — エージェントに、そのタスクに必要な分だけの権限しか渡さない
- ✅ 公開できる出力を制限する — 特にIssueへの自動返信など、外に出せる経路を絞る
- ✅ ユーザー入力を命令と分離する — 誰かが書いた文章を、そのまま“指示”として食わせない
- ✅ 認証情報を隔離する — APIキーやトークンをエージェントの手の届く範囲に置かない
- ✅ 監査ログを完全に残す — 何を読み、何を投稿したかを追えるようにする
⚠️ ここは気をつけて 最大のNGは、「検証していない外部の文章を、AIへの信頼できる命令として扱うこと」です。Issueやコメント、メール本文、Webページ——誰でも書き込めるものは“命令”ではなく“データ”として隔離してからAIに渡す。これが崩れると、いくらモデルを賢くしても漏れます。
あなたへの影響
立場ごとに、受け止め方が変わります。
- AIエージェントを業務に組み込む開発者・チーム: 直接の当事者です。上の3条件が揃っていないか、今日中に権限設定を見直してください
- Claude CodeやCopilotを個人で使う人: 対話的な利用は直接の対象ではありませんが、「自動化・常時アクセス」を設定するときは権限を絞る癖をつけましょう。ツールの全体像はClaudeの使い方完全ガイド2026 が入口になります
- 経営・情報システム側: 「AI導入」を進めるとき、便利さと同じ熱量で「権限の最小化」をルール化する必要があります
まとめ
GitLostが突きつけたのは、**「AIエージェントは、渡された文章を疑わない」**という当たり前の事実です。だから守りは、モデルの賢さではなく権限の設計で決まります。非公開データ・外部入力・外部出口——この3つを同時に握らせない。それだけで、多くの“お願いするだけ”攻撃は成立しなくなります。
AIに仕事を任せる時代だからこそ、「何を任せないか」を決めるのが、いちばん効くセキュリティ対策です。
参考にしたソース
- GitLost: How We Tricked GitHub’s AI Agent into Leaking Private Repos（Noma Security） — 発見者による一次解説
- GitHub AI agent leaks private repos when asked nicely（The Register） — 攻撃の仕組みの報道
- ‘GitLost’ Flaw Leaks Private Data From GitHub’s Agentic Workflows（Dark Reading） — 影響とベンダー対応
- Public GitHub Issue Could Trick GitHub Agentic Workflows Into Leaking Private Repo Data（The Hacker News） — 技術的詳細
- GitLost: GitHub AI Agent Data Leak（Kiteworks） — 3条件と推奨対策の整理
- Prompt injection still drives most agentic AI security failures（Help Net Security） — OWASP 2026の統計
ーー Synth
ヘッダー画像: Photo by Ann H on Pexels
