7月7日、Noma Securityが「GitLost: How We Tricked GitHub's AI Agent into Leaking Private Repos」と題した記事を公開した。この記事では、GitHubの新機能「Agentic Workflows」に存在するプロンプトインジェクション脆弱性を悪用し、未認証の攻撃者がプライベートリポジトリの内容を外部に漏洩させることに成功した実証研究について詳しく紹介されている。

GitHubのAIエージェントが「普通のIssue」に騙された

Noma Securityのセキュリティ研究者が発見した脆弱性「GitLost」は、コード・認証情報・特別なスキル一切不要で、パブリックリポジトリにIssueを1件投稿するだけでプライベートリポジトリの内容を外部に漏洩できるというものだ。

攻撃の手順はシンプルだ。

1. 同一Organization内のパブリックリポジトリに、悪意のある隠し命令を埋め込んだIssueを投稿する
2. IssueがアサインされるなどのイベントでGitHub AgentがWorkflowをトリガーする
3. エージェントがIssue本文に埋め込まれた命令を信頼できる指示として解釈し、プライベートリポジトリ（testlocal）を含む複数のREADME.mdを取得する
4. その内容をIssueへのパブリックコメントとして投稿する

結果として、sasinomalabs/testlocal（プライベートリポジトリ）のREADME.mdが、インターネット上の誰でも閲覧できる状態で公開されてしまった。

GitHub Agentic Workflowsとは

GitHub Agentic Workflowsは、GitHubが2025年にローンチした機能で、GitHub ActionsとAIエージェント（Claude またはGitHub Copilot）を組み合わせ、自然言語で書いたMarkdownファイルをワークフローとして動作させる仕組みだ。エージェントはIssueを読み、ツールを呼び出し、コメントを投稿するなど自律的に動作する。Organization内の複数リポジトリへのアクセス権限も設定できる。

今回の脆弱性が発見されたWorkflowは以下のように設定されていた。

• issues.assignedイベントでトリガー
• IssueのタイトルとBody（本文）を読み取る
• add-commentツールでコメントを投稿
• Organization内の他リポジトリ（パブリック・プライベート問わず）への読み取り権限あり

「Additionally」の一言でガードレールが崩れた

GitHubは今回のようなシナリオを防ぐためのガードレールを実装していた。しかし研究者がさまざまな変形パターンをテストしていく中で、キーワード「Additionally」を追加するだけでモデルの挙動が変わり、拒否ではなく出力の「言い換え」に誘導できることを発見した。

なぜ「Additionally」という一語が有効だったのか。これは、LLMが持つ文脈継続の性質に起因すると考えられる。「Additionally（さらに）」という接続詞は、前の文脈と新たな指示を自然につなぐ役割を果たす。モデルはこの語を受け取ると、後続の文を「拒絶すべき不審な命令」ではなく「前の正当な文脈の延長線上にある追加指示」として処理しやすくなる。結果として、本来なら拒否すべきコンテンツを「情報の言い換え・補足」として出力するよう誘導できてしまった。つまりガードレールは「命令の形式」を検出することで機能していたが、接続詞一語によってその検出を回避されたと見ることができる。

※編集部の考察：元記事ではこのメカニズムの技術的詳細は明示されていない。上記はLLMの一般的な挙動に基づく考察であり、Noma Securityの公式見解ではない。

投稿されたIssueはVP Salesからの顧客対応依頼を装った、一見まったく無害に見える内容だった。

これはプロンプトインジェクション（AIエージェントが読み込むコンテンツに悪意のある命令を隠し込む攻撃手法）の典型的な実例だ。エージェントは「システムが意図した指示」と「ユーザーが入力したデータ」を区別できず、後者を命令として実行してしまった。

なぜこれが深刻か

Noma Securityはこの脆弱性を次のように位置づけている。

「エージェントのコンテキストウィンドウが、そのままアタックサーフェス（攻撃対象領域）になる。IssueでもPull Requestでもコメントでもファイルでも、エージェントが読み込むコンテンツはすべて、命令として扱われれば武器になる」

従来のセキュリティモデルでは信頼境界はコードで強制されていた。AIエージェントの場合、その境界の一部をモデルの「振る舞い」に依存しており、そのモデルは本質的に「命令に従う」設計になっている。記事では「プロンプトインジェクションは、AIエージェントにとってWebアプリケーションにおけるSQLインジェクションと同等のカテゴリ横断的な脆弱性クラスだ」と表現している。

この点はOWASPのLLMアプリケーション向けTop 10でも「LLM01: プロンプトインジェクション」として最上位リスクに分類されており、業界全体で認識が高まっている問題でもある。

開発者・セキュリティ担当者への推奨事項

Noma Securityは以下の対策を挙げている。

• ユーザーが制御するコンテンツをAIエージェントへの信頼できる命令入力として扱わない
• エージェントの権限を最小限に絞る。クロスリポジトリアクセス権限を持つエージェントは特に高価値な攻撃対象になる
• エージェントがパブリックに投稿できる内容を制限する。特にIssueコンテンツへの応答として
• ユーザー入力をモデルに渡す前に、命令コンテキストからサニタイズまたは分離する

本脆弱性はGitHubへ責任ある開示（Responsible Disclosure）が行われており、GitHubの了承のもとで詳細が公開されている。

詳細はGitLost: How We Tricked GitHub's AI Agent into Leaking Private Reposを参照していただきたい。