GitLostは、AIエージェントがハッキングされなくてもデータが漏洩することを証明

攻撃者はパスワードの窃取も、フィッシングメールも、エクスプロイトチェーンも必要とせず、GitHub組織からプライベートなソースコードを引き出しました。やったことは、パブリックなGitHub Issueに一文を入力しただけです。Noma Labsのセキュリティ研究者は2026年7月6日にこの脆弱性を公開し、「GitLost」と命名しました。これはGitHub ActionsとClaudeやGitHub Copilotをバックエンドに持つAIエージェントを組み合わせたGitHub Agentic Workflowsに存在し、従来の意味でのバグではありません。これは、AIエージェントに単一のタスクに必要以上のアクセス権を与え、誰も検証していないコンテンツを読ませたときに何が起こるかを示す実証です。

全体の流れはこうです：エージェント自体はハッキングされていません。設計通りに動作しました。Issueを読み、そのIssueに埋め込まれた指示に従い、与えられたツール（パブリックコメントの投稿）を使って、見知らぬ相手にプライベートリポジトリの内容を渡してしまったのです。Dark Readingは、GitHubがこれを受けてドキュメントを更新したと報じています。Nomaによれば、根本的な設計上の欠陥は公開時点でも依然として存在していました。

この違いは、脆弱性そのものよりも重要です。セキュリティチームはこの20年間、不正アクセスの検知（盗まれた認証情報、権限昇格、ラテラルムーブメントなど）に注力してきました。しかしGitLostはそれらをすべて回避しました。エージェントは正規の権限を持っており、設計通りに動作していました。ただし、本来到達できてはいけない場所にアクセスできてしまったのです。

主なポイント

1. 一文、認証情報ゼロ。

Noma Securityの研究部門であるNoma Labsは、パブリックIssue内に平易な英語のコマンドを隠すことで、アカウント侵害やマルウェア、コーディングスキルなしで、プライベートなGitHubリポジトリのデータを流出させました。

2. ガードレールはたった一語で破られた。

注入した指示の前に「Additionally（加えて）」と付けるだけで、GitHubのAIエージェントはハイジャックを脅威ではなく、正当な追加タスクとして扱うようになりました。

3. 失敗は知能ではなくアクセス。

侵害されたエージェントは、単一のIssueのトリアージタスクを完了するために、組織内のすべてのパブリックおよびプライベートリポジトリへの恒常的な読み取り権限を持っていました。これは組織規模での知的財産の露出であり、単一ポイントの脆弱性ではありません。

4. これは今や主流のパターンであり、例外ではない。

OWASPのGenAIセキュリティプロジェクトは、プロンプトインジェクションをAgentic ApplicationsのTop 10カテゴリのうち6つにマッピングし、プロダクション環境で発生するエージェントAIセキュリティ障害の主因と位置付けています。

5. 多くの組織はギャップの存在すら認識できていない。

Cloud Security Allianceの調査によると、AIアイデンティティガバナンスポリシーを文書化している組織は4社に1社未満であり、非人間アイデンティティ経由の攻撃を阻止できると高い自信を持つ組織はわずか12%です。すべてのAIエージェントの現状のアクセス範囲を、その指定タスクに必要な最小限と照らし合わせてマッピングする正式なリスク評価が、このギャップを埋めるための出発点となります。

GitLost攻撃チェーンの内部：何が起きたのか

Noma Labsが狙ったワークフローはごく一般的なものでした。Issueがアサインされるとトリガーされ、Issueのタイトルと本文を読み、エージェントのコメントツールを使って返信を投稿します。そのために、組織内の他のすべてのリポジトリ（パブリック・プライベート両方）への読み取り権限で動作していました。

認証情報もリポジトリアクセスもコーディングスキルも持たない攻撃者が、内部リクエストに見せかけたパブリックIssueを作成しました。その本文には、プライベートリポジトリからファイルを取得し、その内容をパブリックコメントに貼り付けるよう指示する平易な英語の命令が埋め込まれていました。Issueがアサインされると、エージェントはそのテキストを読み、埋め込まれた指示を正規タスクの一部として扱い、プライベートファイルを取得してパブリックに投稿しました。Nomaの実証実験では、数分でプライベートリポジトリのデータをこの方法で引き出すことができました。

マルウェアもエクスプロイトもアカウント乗っ取りもありません。ただ、エージェントが通常業務の一部として読むよう設計されているコンテンツ内の言語だけです。

この点こそ、すべてのCISOが直視すべき部分です。これは一般的な意味でのアクセス制御の失敗ではありません。エージェントは設定された通りのアクセス権を持っていました。失敗は、「設定されたアクセス権」の意味がどこまで許容されていたかにありました。エージェントが個別のリクエストごとに認可チェックなしで到達できるすべてのプライベートリポジトリファイルは、潜在的な流出ペイロードとなります。リポジトリコンテンツへのデータ分類を適用すれば、流出時に最も高い規制リスクや競争上のリスクを持つ資産がどれかを最低限把握できます。

ガードレールはたった一語で破られた

GitHubには、これを防ぐためのガードレールが設計されていました。Nomaの研究者は攻撃者と同じ手法でワークフローをテストし、フレーズを変えながら何が通るかを試しました。最も効果的だったのは、驚くほど単純なものでした。「Additionally」という単語を指示の前に付けるだけです。

もう一度読んでください。ハイジャックの試みを通常の追加タスクとして再解釈させるために選ばれたたった一語が、モデルを拒否ではなく従わせるのに十分だったのです。

これは、プロンプトレベルのフィルタリングにAIセキュリティプログラムを賭けている人なら誰でも警戒すべき部分です。たった一つの接続詞で突破される防御は、防御とは呼べません。それは単なるスピードバンプ（減速帯）であり、攻撃者は好きなだけ非公開で何度でも試行できるため、スピードバンプでは止められません。

プロンプトインジェクションはもはや理論上のリスクではない

GitLostは例外ではありません。これが今の主流パターンです。OWASP GenAIセキュリティプロジェクトのState of Agentic AI Security and Governance（バージョン2.01）は、プロンプトインジェクションをAgentic ApplicationsのTop 10カテゴリのうち6つにマッピングし、Help Net Securityによる2026年の報道でも、プロンプトインジェクションが現在プロダクション環境で発生しているエージェントAIセキュリティ障害の主因であると特定しています。

根本原因はアーキテクチャにあり、より優れたモデルでいずれ解決される「学習ギャップ」ではありません。大規模言語モデルは、システムプロンプト、ユーザーリクエスト、外部ソースから取得したテキストをすべて一つのトークンストリームとして処理します。これらのトークンの一部を信頼できるコマンド、他を信頼できないデータとして区別する信頼できる仕組みはありません。GitHub Issueやカレンダー招待、顧客メールに隠された悪意ある一文も、実際のオペレーターからの指示と同じ権限でモデルに解釈されます。

このアーキテクチャ上の事実こそ、「より良いシステムプロンプトを書けばよい」という戦略が失敗し続ける理由であり、GitLostも例外ではありません。

GitLostだけではありません。研究者は、15回のクリーンリリース後に密かに流出コードを追加したModel Context Protocolパッケージに、CVSSスコア9.6のリモートコード実行脆弱性（CVE-2025-6514）を公開しました（OWASPが引用しHelp Net Securityが報道）。また、Cursorコーディングエージェントに対するCVE-2026-22708では、攻撃者がエージェントの実行環境を汚染することで、許可リスト化されたコマンド自体を任意ペイロードの配信手段に変えることができると示されました。許可リストがあったことで攻撃が容易になったのです。OpenAIのCodex CLIに対するCVE-2025-59532では、エージェント自身の出力がサンドボックスの境界を再定義できることが示されました。

3つの異なるベンダー、3つの異なるメカニズム、1つの共通する根本原因：エージェントが本来敵対的とみなすべきコンテンツやコマンドを信頼し、アクセス範囲が十分に絞られていなかったため、被害が拡大しました。これらの経路によるデータ侵害も、認証情報侵害と同様の規制通知義務が発生します。流出チャネルがAIであっても、発覚時点からコンプライアンスのカウントダウンは始まります。

本当の脆弱性はモデルの挙動ではなく恒常的なアクセス権

ここからが本質的な問題です。このようなインシデントが起きると、セキュリティ業界は「なぜ”Additionally”で騙されたのか」「どんなフィルターで防げたのか」「どのベンダーが最初にパッチを出すのか」とモデル自体を問い詰めがちです。しかしそれは、症状を病気と取り違えています。

GitLostエージェントが本来必要だったのは、1つのリポジトリの1つのIssueを読む権限だけです。しかし実際には、組織内すべてのリポジトリ（パブリック・プライベート両方）への恒常的な読み取り権限を無期限に持っていました。タスクに必要な権限とアイデンティティに付与された権限のギャップこそが、実際の被害を生みました。プロンプトインジェクションは単なる引き金に過ぎません。

これは「オールアクセス・エージェント」と呼ぶべき状況です。多くの組織は、AIエージェントを2005年のIT部門がサービスアカウントを発行したのと同じように、広範で恒常的、かつほとんど見直されない形でプロビジョニングしています。しかも今や、その認証情報は、誰でも一文書き込めば使わせることができるシステムの背後にあります。

Cloud Security AllianceのState of Non-Human Identity and AI Security調査レポートは、このギャップがどれほど広がっているかを数値で示しています。AIアイデンティティの作成や廃止を管理する正式なポリシーを文書化・採用している組織は4社に1社未満。非人間アイデンティティ経由の攻撃を防げると高い自信を持つ組織はわずか12%。AI関連アイデンティティの新規作成をそもそも記録していない組織も16%以上に上ります。

12%。これは成熟度モデルの丸め誤差ではありません。10人中9人近くのセキュリティリーダーが、明日自分の組織で同じことが起きても止められないと認めているのです。人間のベンダーアクセスだけを管理し、同じベンダーがプロビジョニングしたAIエージェントアイデンティティには適用していないサプライチェーンリスク管理プログラムは、エンタープライズで最も急増している非人間アイデンティティの管理を見落としています。

ガードレールだけでは失敗し続ける理由

GitLostへの直感的な対応策は2つありますが、どちらも間違いです。

1つ目は、技術が成熟するまでエージェントAIを全面的にブロックすることです。GitHub Agentic WorkflowsやCopilot連携を凍結し、ベンダーの対応を待つ。しかしこれは、エージェントによる24時間体制のIssueトリアージがもたらす生産性を放棄することになり、競争市場では通用しません。エンジニアリングチームが「NO」と言われれば、公式・非公式を問わず回避策を見つけます。その回避策がシャドーAIです。ポリシーの外で監査もアクセス範囲の見直しもないエージェントが動き出します。

2つ目はモデルを信頼することです。より良いプロンプトを作り、ベンダーの最新ガードレールアップデートを適用し、「Additionally」は次のモデルで検出される単発バグだと考える。GraviteeのState of AI Agent Security 2026レポートは、この賭けがどうなっているかを示しています。プロダクションAIエージェントを運用する組織の88%が、過去1年に関連するセキュリティインシデントを確認または疑っており、82%の経営層は既存ポリシーで不正なエージェントアクションから守られていると答えています。

どちらも事実です。両立しています。経営層は守られていると信じ、インシデントデータは逆を示しています。この自信と現実のギャップこそ、GitLost型攻撃が成立する余地であり、プロンプトエンジニアリングでは埋まりません。なぜならガードレールが存在する層が間違っているからです。

解決策はAIをブロックすることでも、盲信することでもありません。人間のアクセスと同じようにエージェントのアクセスを扱うことです。多くの組織がまだそこまで手が回っていないだけです。

AIエージェント導入の裏に潜むガバナンスギャップ

自社データにAIエージェントを使っている組織は、すでに「そのエージェントがどこまで見えるか」について暗黙の決定を下しています。しかし、その多くは意図的に決めたわけではありません。

恒常的で広範、ほとんど監査されないアクセスがデフォルトになっているのは、誰かがそう選んだからではなく、タスクごとにアクセス範囲を絞るより、一度プロビジョニングして終わりにするほうが楽だからです。これは、サービスアカウントの権限が肥大化し、忘れ去られたIAMロールや、誰も覚えていないサードパーティ連携が生まれたのと同じ近道です。Agentic AIはさらに高速で多くのシステムに触れ、GitLostが示すように、パブリックな場で一文書ける人なら誰でも操作できてしまいます。

Noma自身が開発者向けに出している推奨事項は優先順位が明確です：ユーザーが制御するコンテンツを信頼できる指示入力として扱わないこと、エージェントがパブリックに投稿できる内容を制限すること、そして最優先は「タスクに必要な最小限まで権限を絞ること」です。このうち2つはモデル自体とは無関係です。データガバナンスの話です。AIエージェントのアクセス範囲にデータ最小化を適用し、各エージェントに指定タスクに必要な特定のリポジトリ、ファイル、データタイプへの読み取り権限だけを付与することが、このガバナンス原則の運用上の実装です。

規制当局も、業界が自力で解決するのを待っていません。OWASPのレポートは、すでにAIインシデント対応を扱う10の法域で42の規制文書を追跡しており、通知期限も四半期単位ではなく「数時間」で定めるものもあります。インシデント当日に「このエージェントは何にアクセスできたか」と答えられない組織は、規制当局はもちろん顧客も満足させるスピードで対応できません。AIエージェントによる流出シナリオ（GitLostが実証した「エージェントがプライベートデータをパブリックに投稿した」ケースを含む）を明示的にカバーしたインシデント対応計画を文書化しておけば、混乱した事後対応を、訓練された時間内対応に変えられます。

ギャップを本当に埋めるもの：スコープ管理されたAIエージェントアクセス

「モデルが悪意ある指示に耐えられるか」を問うのはやめましょう。本当に重要なのは、「このエージェントが今ハイジャックされたら、何にアクセスできるか？」です。

これに答えるには、曖昧な「AIガバナンス」ではなく、4つの具体的なコントロールが必要です。

• アイデンティティ単位ではなくタスク単位でアクセス範囲を設定する。 1つのIssueをトリアージするエージェントに、組織内すべてのプライベートリポジトリへの恒常的な可視性は不要です。ロールベースや属性ベースアクセス制御ポリシーで、すべてのリクエストを分類・機密性・コンテキストに基づいて評価し、一度広範な権限を付与するのではなく、そのタスクに本当に必要な範囲に絞り込みます。これは20年にわたり人間アカウントに適用されてきた最小権限の原則を、今や数で上回るAIアイデンティティにも拡張するものです。
• 認証情報を推論レイヤーから分離する。 エージェントが利用するトークンは、言語モデル自体が決して参照できないキーチェーンやボールト内に保管すべきです。KiteworksのSecure MCP Serverはまさにこの原則に基づいて設計されており、OAuth認証情報はOSの資格情報ストアに保存され、LLMのコンテキストには決して渡されません。これにより、エージェントがハイジャックされても、現在のセッションで許可された範囲を超えて鍵を抜き出すことはできません。
• エージェント自身の意図表明とは独立してデータレイヤーをガバナンスする。 エージェントの目的表明はセキュリティコントロールではなく、エージェント自身が生成した「提案」に過ぎません。Kiteworks Compliant AIは、すべてのAIリクエストに対し、RBACおよびABACポリシー判断をリアルタイムでコンテンツレイヤーに適用し、エージェント自身の推論が「許可すべき」と結論付けたかどうかに関係なく制御します。CISOダッシュボードはすべてのAIデータアクセスイベントをリアルタイムで可視化し、エージェントによる異常な挙動を流出完了前に検知するための行動監視をセキュリティチームに提供します。
• 流出チャネルはエージェントが既に持つ正規ツールだと想定し、監査する。 GitLostは新たな機能を必要としませんでした。エージェントが本来使うべきコメント投稿機能を流用しただけです。エージェントが触れたすべてのファイルと出力内容の完全な改ざん検知付き監査証跡があれば、インシデントは謎ではなく5分で調査できる事実となります。これらのログをリアルタイムでSIEMに連携すれば、単一の監査ログだけでは見抜けない多段階の流出パターンも相関分析で検知できます。

これらはプロンプトインジェクション自体の発生を防ぐものではありません。現時点でそれを確実に防げる製品は存在しません。インジェクションが流出になるかどうかを決めるのは、モデルが騙されるかどうかではなく、騙されたエージェントが盗む価値のあるものにアクセスできるかどうかです。

月曜朝にやるべきこと

どのAIベンダーのガードレールが優れているか議論するのはやめ、既存エージェントが実際にどこまで到達できるかを監査しましょう。

自社のリポジトリやファイルストア、ゼロトラスト・データ交換環境にアクセスできるすべてのAIエージェントや自動化ワークフローの権限リストを洗い出します。それぞれについて、エージェントが本来やるべきタスクを書き出し、実際に許可されているアクセス範囲と突き合わせます。この2つのリストが一致しない箇所があれば、そこが次のGitLostの温床です。

その後は、プロンプト層ではなくアクセス層でギャップを修正します。権限はタスク単位に絞り、認証情報はモデルから完全に隔離します。すべてのAI駆動データリクエストは、エージェントの意図表明に依存しないポリシーエンフォースメントを必ず経由させます。すべての操作を、いつか監査人に求められるつもりで記録します。いずれ必ず求められるからです。

次のGitLostで被害を受ける組織は、どのモデルがより安全かを議論し続け、そもそもエージェントが到達してはいけない場所を把握していなかったところです。

次のGitLost型インシデントが自社を襲う前に、AIエージェントのデータアクセスガバナンスについて詳しく知りたい方は、今すぐカスタムデモをお申し込みください。

追加リソース

• ブログ記事
  ゼロトラストで実現する手頃なAIプライバシー保護戦略
• ブログ記事
  77%の組織がAIデータセキュリティで失敗している理由
• eBook
  AIガバナンスギャップ：2025年に91%の中小企業がデータセキュリティでロシアンルーレット状態に
• ブログ記事
  あなたのデータに「–dangerously-skip-permissions」は存在しない
• ブログ記事
  規制当局は「AIポリシーがあるか」を問うのをやめました。今求められるのは実効性の証明です。