GitLost: GitHub Agentic Workflowsで公開Issue経由のprivate repo漏洩をNoma Labsが実証

2026.07.08
この記事は約14分で読めます。

AIセキュリティ企業Noma Security(Noma Labs)は2026年7月6日、GitHubがパブリックプレビュー(public preview)として提供しているGitHub Agentic Workflowsに対する間接プロンプトインジェクション攻撃「GitLost」を公開しました。攻撃者は対象組織の公開リポジトリに一つのGitHub Issueを投稿するだけで、AIエージェントが持つ組織内の非公開リポジトリ読み取り権限を悪用し、内部データを公開コメントとして漏洩させられます。認証情報の窃取、コーディングスキル、コード実行環境への侵入はいずれも不要で、必要なのは対象組織の公開リポジトリでIssueを開ける権限だけです。

GitHub Agentic Workflowsは、GitHub ActionsとAIエージェントを組み合わせた自動化基盤で、開発チームがMarkdown形式の自然言語でワークフローを記述すると、GitHubがそれをYAML形式のActions定義にコンパイルして、Claude、GitHub Copilot、Google Gemini、OpenAI Codexなど選択可能なバックエンドAIモデルを介して実行します。GitHubは2026年2月13日にテクニカルプレビュー(technical preview)として公開し、2026年6月11日にパブリックプレビューへ移行しました。GitLostが浮き彫りにしたのは、こうしたエージェント基盤に共通する構造的な問題です。エージェントが読み込む任意の入力、Issue本文、プルリクエスト、コメント、ファイル内容などが、そのままエージェントへの指示として作用し得る点、そしてGitHubが実装済みの複数のガードレールが「Additionally」という一語のプレフィックスで回避可能である点が、Noma Labsの実証で明らかになりました。Nomaおよび報道各社は、GitLostを単一のコード修正で閉じる脆弱性というより、エージェントに広い権限を与えた状態で外部入力を読ませるアーキテクチャ上の問題として整理しています。

GitLost脆弱性の全体像

本脆弱性はGitHub Agentic Workflowsに存在する間接プロンプトインジェクション型の攻撃面で、CVE番号は公表時点で発行されていません。Noma LabsはGitHubへの責任ある開示を経て技術詳細を公開しています。GitHubは公式ドキュメントでも、AIエージェントがプロンプトインジェクションや悪意あるリポジトリコンテンツの影響を受け得ることを前提に、多層防御の必要性を説明しており、GitLostはその想定が実運用構成で現実の脅威になることを実証した形です。

項目 内容
脆弱性通称 GitLost
CVE番号 該当なし(GitHubはアーキテクチャ上の限界として個別脆弱性扱いをしていない)
脆弱性クラス Indirect prompt injection(間接プロンプトインジェクション)
影響製品 GitHub Agentic Workflows(2026年2月13日にテクニカルプレビュー、2026年6月11日にパブリックプレビュー移行)
対象バックエンドLLM Claude、GitHub Copilot、Google Gemini、OpenAI Codex(構成で選択)
発見・公表 Noma Security(Noma Labs)、Security Research LeadのSasi Levi氏が主導
公表日 2026年7月6日
攻撃前提条件 対象組織がGitHub Agentic Workflowsを有効化、ワークフローがIssueイベントでトリガー、エージェントが公開/非公開リポジトリを横断する読み取り権限と公開コメント投稿権限を保有
攻撃実行に必要な権限 対象組織の公開リポジトリでIssueを開ける権限のみ。対象組織の認証情報や権限は不要。
攻撃効果 エージェントの読み取り権限範囲内にある非公開リポジトリ内容の公開Issueコメント経由での漏洩。リポジトリ内にソースコード、設計書、内部キー、CI/CD関連情報などが含まれていれば、それらも露出対象になり得る。
GitHubガードレール回避手法 悪意ある指示の先頭に「Additionally」を付与することで、モデルが拒否対象ではなく後続タスクとして処理
GitHubの対応 NomaがGitHubへ責任ある開示を実施し、GitHubの認知のもと技術詳細を公開。Nomaおよび報道では、単一パッチではなく権限スコープ、入力分離、出力制限で対処すべきアーキテクチャ上の問題として整理されている。
Nomaの過去関連研究 GrafanaGhost(2026年4月、同種のキーワードバイパス)

GitHub Agentic Workflowsという新しい攻撃面

GitHub Agentic Workflowsは、GitHubが2026年2月13日にテクニカルプレビューとして公開し、6月11日にパブリックプレビューへ移行した自動化機能で、従来のGitHub Actionsをコード中心の記述から自然言語中心の記述へと転換するものです。開発者は`.md`(Markdown)ファイルにワークフローを平文で記述し、GitHubがそれをYAMLベースの`.yml` Actionsファイルにコンパイルします。実行時にはAIエージェントがIssue本文やプルリクエストを読み、設定されたツールを呼び出して、コメント投稿などのアクションを自律的に実行します。バックエンドとして選択できるAIモデルはClaude、GitHub Copilot、Google Gemini、OpenAI Codexの4種類で、組織はワークフローごとに使用するモデルを構成可能です。

Agentic Workflowsが特に想定している用途の一つがIssueトリアージと自動応答です。「新しく作成されたIssueを読み、関連する公開/非公開ドキュメントを横断して調査し、担当者にコメントで要約を返す」といったワークフローを、Markdown数行の自然言語指示で組み立てられます。ただしIssueは公開リポジトリでは誰でも作成できるため、この用途は必然的に外部入力を信頼境界の内側に取り込む構造になります。GitLostが突いたのは、この構造そのものです。

間接プロンプトインジェクションの原理

プロンプトインジェクションとは、AIエージェントが読み込むコンテンツの中に悪意ある指示を隠し、エージェントが本来の運用者からの指示ではなくその隠された指示に従うよう仕向ける攻撃クラスです。直接的な攻撃は攻撃者がエージェントとの会話に直接指示を投入する形ですが、間接的なプロンプトインジェクションは、エージェントが業務中に読む文書やデータの中に指示を潜ませておき、エージェントが「データ」だと思って読んだテキストが「指示」として解釈されることを狙います。

Noma LabsのSecurity Research LeadであるSasi Levi氏は、GitLostが従来のプロンプトインジェクションと質的に異なる点をこう述べています。「これまでのプロンプトインジェクションの多くは、エージェントが何を『言う』かを操作する話でした。GitLostは、エージェントが自身の権限で何を『する』かを操作する話です」。エージェントは単なるチャットウィンドウではなく、組織のCI/CD隣接インフラの内側に座る認証済みアクターで、攻撃者本人が持たないリポジトリへの読み取り権限を持っています。攻撃者がその権限を借用する形で、内部データを外部に流出させるのがGitLostの本質です。

従来のセキュリティ境界はコードで強制されるものでしたが、エージェント型システムでは境界の一部がモデルの振る舞いに委ねられます。そしてモデルは本質的に「指示に従う」ように訓練されているため、境界を破る指示に対して脆弱です。Nomaはこの構造を、AIエージェントに対するプロンプトインジェクションはWebアプリケーションに対するSQLインジェクションに相当する体系的かつカテゴリ横断的(systematic, category-wide)な脆弱性クラスだと整理しています。

GitLost攻撃チェーンの全体像

Noma Labsの実証は、次のような流れで進みます。まず攻撃者は、対象組織の公開リポジトリに一つのGitHub Issueを作成します。Noma Labsが使用したPoCでは、「Sales部門VP」の名義で顧客ミーティング後のドキュメント調査を依頼するもっともらしい体裁を装いました。Issueの本文には、通常のリクエスト文の中に、エージェントに対する平易な英語の指示が埋め込まれています。

次に、GitHubの自動化機構がこのIssueを担当者に割り当てた瞬間、`issues.assigned`イベントでワークフローがトリガーされます。エージェントはIssueのタイトルと本文を読み、Nomaの構成では公開リポジトリと非公開リポジトリを横断する読み取り権限、および同Issueへのコメント投稿ツールが与えられていました。エージェントは埋め込まれた指示を後続タスクとして処理し、`sasinomalabs/poc`と`sasinomalabs/remote-ping`(公開)、そして`sasinomalabs/testlocal`(非公開)のREADME.md内容を取得します。最終的に、取得した内容を元の公開Issueへのコメントとして投稿しました。この時点で内容はインターネット上の誰からでも閲覧可能な状態になります。

攻撃実行に必要な条件はごく単純で、対象組織がAgentic Workflowsを有効化し、そのワークフローが公開Issueを入力として受け取り、非公開リポジトリへの読み取り権限を持ち、公開コメントを投稿できるように構成されていること、これだけです。攻撃者側にはコーディングスキル、認証情報、システムへの直接アクセスは一切必要ありません。

「Additionally」一語によるガードレール回避

GitHubはこの種の攻撃を想定して、Agentic Workflowsに複数のガードレールを実装していました。既定でリポジトリトークンを読み取り専用に絞る、実行時のサンドボックス、入力のクリーニング、そしてエージェントが投稿しようとしている出力を投稿前にスキャンする脅威検出ステップです。仕組みとしては業界標準に近い多層防御で、実際にNoma Labsの初期の試行では、これらのガードレールが単純な悪意指示を拒否していました。

ところがNomaは、悪意ある指示の先頭に「Additionally」(さらに)という一語を付けるだけで、これらの防御を通過することを発見しました。モデルは「Additionally」以下の内容を「拒否すべき別の指示」ではなく「本来のタスクに追加する後続作業」として解釈し、指示の意味論を再フレームします。結果として、単独では拒否されていた指示が、この一語のプレフィックスと組み合わさると通ってしまう挙動が確認されました。この現象自体はNoma自身が2026年4月に公開したGrafanaGhostの研究でも類似の観測がなされており、キーワードによる意味論の書き換えが複数の商用エージェント基盤で通用することが示唆されています。

Nomaは、このガードレール回避が示すのは「フィルタは補助防御にはなるが境界にはならない」という設計上の事実だと整理しています。自然言語には、SQLのような明示的な「データ」と「命令」の構文的境界が存在しないため、モデル出力段で悪意プロンプトを検出しようとする防御は、言い換えや語順の変化に対して原理的に脆弱です。

アーキテクチャ上の限界とGitHubの対応

Noma LabsはGitLostをGitHubに責任ある開示のプロセスで報告しました。GitHub側の受け止め方は、通常のCVE発行を伴う脆弱性としてではなく、Agentic AIシステム全般に共通する「アーキテクチャ上の限界」というものでした。The Registerによれば、Nomaが提案した修正内容もコード変更ではなく「組織がAPIキーやリポジトリアクセスをエージェント間でどう共有するかについてのドキュメント上の注意喚起」でしたが、報道時点でGitHubはそのドキュメント修正を実装した形跡が確認されていません。

この対応の背景には、根本的にはコード側で塞ぎ切れる問題ではないというNomaと業界共通の認識があります。エージェントが公開Issueを読める設計、非公開リポジトリへの横断的読み取り権限、公開コメント投稿ができる構成、これらすべてがワークフロー設計者が意図して与えたものです。エージェントは付与された権限内で「合法的に」動作しており、その動作の起点となる自然言語指示の解釈こそが攻撃者の手中にある、という構図です。Sasi Levi氏の応答は、責任は組織側のトークン設計と権限スコープの見直しにあるという立場に近いものです。

AIエージェント攻撃面の系譜

GitLostは、2026年に相次いで公表されたAIエージェント×セキュリティ研究の一連の流れに位置付けられます。同月にHong Kong University of Science and Technologyが公開したSkillCloak(Cloak and Detonate論文)は、AIエージェント用Skillパッケージが静的スキャナを90％以上バイパスする手法を実証し、ClawHub上の実観測1,613個の悪意Skillでの評価も含まれていました。SkillCloakが供給側(マーケットプレイス配布Skill)の汚染に着目したのに対し、GitLostは需要側(組織内で稼働するエージェント)の入力信頼境界の破綻に着目しています。両者は攻撃面の別々の側面ですが、いずれも「AIエージェントの権限を借用して悪意ある動作を実行させる」という同じ構造を持ちます。

また、2026年2月にはGitHub Codespaces経由でGitHub CopilotがGitHub tokenをプロンプトインジェクションで漏洩させる脆弱性が修正され、同年4月にはMicrosoftの公開リポジトリでtriple-quote string terminatorとPythonコードインジェクションを組み合わせたGitHub tokenの漏洩が報告されています。同月にはNoma自身のGrafanaGhostも公開され、キーワードベースのガードレールバイパス手法が観測されています。個別のバグではなく、公開Issueと認証済みエージェントを組み合わせた攻撃パターンが、複数のプラットフォームで系統的に発掘されている状況です。

実務対応と組織設計の見直し

Noma Labsが推奨する対策と、報道各社が業界専門家から集めた見解を統合すると、GitLostに対する実務対応は次の観点に集約されます。単一のパッチではなく、組織のエージェント運用アーキテクチャそのものを見直す必要があります。

  • ユーザ制御コンテンツを指示として扱わない:公開Issue、公開プルリクエスト、外部プルリクエストのコメント、外部から取得したファイルなど、攻撃者が内容を制御し得るあらゆる入力は、エージェントに対する「指示」ではなく「調査対象データ」として扱う設計を徹底します。可能であれば、指示コンテキストとユーザ入力をモデルに渡す前段で構造的に分離します。
  • トークンスコープを最小権限に絞る:「便利のため」に組織全体を横断する読み取り権限をエージェントに付与する慣行を見直します。トリアージ対象のリポジトリ1個に限定したトークンは、組織全体読み取り権限のトークンより「はるかに危険度が低い」と、Nomaは強調しています。Personal Access Tokenの発行段階でリポジトリスコープを厳密に絞ることが実務的な第一歩です。
  • 公開出力チャネルを制限:エージェントが公開場所にコメントを投稿できる範囲を明示的に制限します。GitLostのような外部送信型(exfiltration)攻撃では、公開コメントが漏洩チャネルとして使われます。エージェントの出力先を非公開の内部システム(社内Slack、Issue tracker等)に絞ることで、少なくとも即時漏洩は防げます。
  • 公開Issueと非公開データを同じエージェントに触れさせない:公開入力を処理するエージェントと、非公開データにアクセスするエージェントを別インスタンスに分離します。単一エージェントが両方に触れる構成は、GitLost型攻撃の必要十分条件そのものです。
  • 人間の承認ステップの復活(Human-in-the-loop):機密性のあるアクション(外部投稿、非公開データの読み取り、権限昇格を伴うAPI呼び出しなど)については、エージェントが自律実行する前に人間の承認ステップを挟むワークフロー設計を推奨します。「自動化の効率」と引き換えに失うものが何かを、機能ごとに評価する必要があります。
  • ガードレールを絶対視しない:入力サニタイズ、出力フィルタ、脅威検出モデルは補助防御として価値がありますが、「Additionally」型の一語バイパスが繰り返し発見されている以上、これらのみで攻撃面が閉じるとは考えない前提での多層防御が必要です。トークンスコープと出力チャネル制限が、フィルタ側の副次的対策より優先されます。

Nomaの主張を要約すれば、「自律型エージェントは、静かなデータ漏洩や秘密情報の露呈のリスクであってはならない」というのが業界に投げかけられた問いです。セキュリティチームが自律型エージェントを承認する前に、そのエージェントが持ち得るすべての接続、アクセス、経路、そしてエージェントアクセスの潜在的な影響半径と権限を理解しておく必要があります。「見えないものを守ることはできない」という点に集約されるSasi Levi氏の指摘は、GitLostの個別事案を超えて、Agentic AI導入を進めるすべての組織に共通する要請です。

一次情報・公式情報

参考情報

コメント

タイトルとURLをコピーしました