Noma Labsの研究者たちは、GitHubが新たにリリースしたAgentic Workflowsが、プライベートリポジトリのファイルを公開してしまうよう騙される可能性があることを実証しました。これは、公開されたIssueのコメントがたった一つあるだけで、内部のAIアシスタントがデータ漏洩の経路になり得ることを示しています。
この欠陥が重大なのは、特別なエクスプロイトコードを使用することなく、GitHubの組み込みの安全チェックをバイパスできるためです。攻撃者は、AIエージェントが読み取って実行してしまうような、一見無害なIssueを作成するだけで十分です。
脆弱性の仕組み
Agentic Workflowsは、ワークフローファイルで定義されたコマンドを実行することで、AIエージェントが新しいIssueなどのGitHubイベントに反応できるようにするものです。Noma Labsは、エージェントが正当なワークフローの指示と、ユーザーが投稿したコメントに含まれるテキストを区別していないことを発見しました。マネージャーの依頼を模倣した公開Issueを投稿し、そこに隠された指示を付け加えることで、攻撃者はエージェントを以下のように誘導できます。
- Issueを開く（公開状態で表示される）。
- 一見普通に見えるが、隠れたコマンドを含む行を含める。
- ワークフローが読み取りを許可されているプライベートリポジトリから、AIにファイルをフェッチ（取得）させる。
- 取得した内容を、同じIssueへの返信としてエージェントに投稿させる。
研究者たちは、隠されたコマンドの前に「Additionally,」という単語を一つ挿入するだけで、GitHubのガードレールをすり抜けるのに十分であることを発見しました。追加の権限、トークン、カスタムコードは必要ありません。適切な言い回しさえあればよいのです。
単なるバグにとどまらない理由
この問題は構造的なものです。AIエージェントは、リポジトリのイベントから受け取ったあらゆるテキストを信頼できるものとして扱うため、実質的にユーザー生成コンテンツが、WebアプリケーションにおけるSQLインジェクションのような入力ベクトルとなってしまいます。もしワークフローがエージェントに対してプライベートリポジトリへの読み取り権限と、公開コメントを投稿する権限の両方を与えている場合、その組み合わせによってデータ流出への直接的な経路が生まれます。
GitHubの見解
GitHubにはこの欠陥が通知されています。
チーム向けの緩和策
- エージェントの権限を制限する: プライベートリポジトリへの読み取り/書き込み権限は、絶対に必要な場合にのみ付与してください。
- 公開投稿をブロックする: エージェントが公開Issueに対してコメントやその他の成果物を公開できないように、ワークフローを設定してください。
- すべての外部入力を信頼できないものとして扱う: ユーザー生成テキストがAIに届く前に、それをサニタイズ（無害化）したり無視したりする検証レイヤーを追加してください。
- ワークフローのトリガーを監査する: どのイベント（Issue、Pull Requestなど）がエージェントを呼び出すのかを確認し、関連する権限が意図したユースケースと一致しているかを検証してください。
まとめ: プライベートコードを読み取り、かつ公開投稿ができるAIアシスタントの安全性は、その周囲に設定した境界線の安全性に依存します。厳格な権限制限と入力のサニタイズがなければ、たった一つの公開コメントが、生産性向上のための機能をデータ漏洩の経路へと変えてしまう可能性があります。