今回の調査結果は、企業コードへの特権アクセスを持つAIエージェントのセキュリティに新たな懸念を投げかけています。
Noma Securityの新たな調査によると、プロンプトインジェクション攻撃を使うことで、GitHubのプレビュー版Agentic Workflowsを騙してプライベートリポジトリのコンテンツを取得させ、それを公開の場に投稿させることが可能だといいます。企業がソフトウェア開発環境に特権アクセスを持つAIエージェントを導入する中、より広範なリスクが浮き彫りになっています。
このAIセキュリティ企業は、「GitLost」と名付けたこの攻撃についてブログ投稿で詳細を明らかにしました。それによると、認証を持たない攻撃者であっても、細工したGitHub Issueを公開リポジトリに投稿するだけでGitHubのプレビュー版Agentic Workflowsを悪用できるといいます。もしAIエージェントが同一組織内のプライベートリポジトリへの読み取りアクセス権を持っていた場合、機密情報を取得し、それを公開コメントとして投稿してしまう可能性があると同社は述べています。
GitHub Agentic Workflowsは、GitHub ActionsとClaudeやGitHub CopilotといったAIモデルを組み合わせたもので、開発者はMarkdownでワークフローを定義できます。同時に、AIエージェントはissueを読み込み、ツールを呼び出し、開発者に代わってタスクを実行します。
「GitHubのエージェントが、信頼すべきでない内容を読み込んでしまったらどうなるでしょうか」と、Nomaの研究者であるSasi Levi氏は記しています。「答えは、教科書通りの間接的プロンプトインジェクション攻撃です。これはインターネット上の誰にでも密かにプライベートデータを送り届けてしまう類の攻撃です」
公開されたGitHub Issueが攻撃経路に
Nomaによると、この攻撃は盗まれた認証情報やマルウェア、ソフトウェアの脆弱性に依存するものではありません。その代わりに、攻撃者は公開リポジトリに投稿したGitHub Issueの中に、隠された指示を埋め込んでいました。
AIエージェントがそのissueを、信頼できない内容としてではなく指示として解釈してしまったため、プライベートリポジトリにアクセスし、その内容を公開issueに投稿してしまったとブログ投稿では述べられています。
「GitLostの脆弱性の根本原因は、今となってはエージェント型AIシステムではおなじみのもの、つまりプロンプトインジェクションです」とLevi氏は記しています。「今回のケースでは、悪意ある行為者は誰でもGitHub Issueを作成し、その本文に、GitHubのエージェントが従ってしまうような平易な英語の指示を隠すことができます」
この攻撃を実証するため、研究者らはドキュメントの更新を求める、一見ごく普通のGitHub Issueを作成しました。ワークフローがトリガーされると、AIエージェントはプライベートリポジトリからREADMEファイルを取得し、その内容を誰でも閲覧できる公開コメントとして投稿してしまいました。
研究者らはまた、文言をわずかに変えるだけで、AIエージェントが以前は拒否していた指示に従うようになり、GitHubのプロンプトベースのガードレールを回避できたとも述べています。
GitHubは、コメントを求める取材依頼に直ちには応じませんでした。
より広範なAIエージェントのリスクを示唆する調査結果
Nomaは、GitLostがGitHub固有の欠陥というより、AIエージェントが抱えるより広範なアーキテクチャ上の課題を示していると述べています。
「問題は、GitHubのAIエージェントが特別に安全性を欠いているということではありません」とLevi氏は記しています。「問題は、信頼できない外部コンテンツと機密性の高い内部リソースの両方にアクセスできるAIエージェントであれば、信頼境界が適切に強制されていない限り、意図せずその両者をつなぐ橋渡し役になってしまう可能性があるということです」
独立系サイバーセキュリティ研究者でレッドチーム担当者でもあるVibhum Dubey氏は、今回の調査結果はプロンプトインジェクション単体よりもさらに根本的な問題を露呈していると述べています。
「これは抽象的な意味でのプロンプトインジェクションではありません。GitHubが、エージェントのセキュリティを整備する前にエージェントの権限を出荷してしまったということなのです」とDubey氏は述べています。「この脆弱性が露呈しているのは、AIエージェントがユーザー権限モデルではなく、サービスアカウント権限モデルの上で動作しているということです。これは、セキュリティチームがLLMを攻撃ベクトルとして考慮する以前に立てていたアーキテクチャ上の前提です」
Dubey氏によると、プロンプトインジェクション自体はほとんど二次的な問題に過ぎないといいます。
「危険なのは、信頼境界がGitHubのデータモデル上には存在していても、エージェントの実行コンテキスト上にはどこにも存在していないということです」と同氏は述べています。「エージェントは、あるリポジトリがプライベートであるということを『知っている』わけではありません。ただ『アクセス可能』であると見なしているだけです。より多くの組織がエージェントを導入するにつれ、こうした目に見えない権限の隙間が積み重なっていくことになります」
専門家、AIエージェントへのより厳格な統制を求める
Dubey氏は、この問題を主として監視上の課題として扱うのではなく、組織はAIエージェントへの権限付与の在り方そのものを見直すべきだと述べています。
「具体的な対策は3つあります。エージェントには、幅広いサービスアカウントアクセスではなく、明示的なリポジトリのホワイトリストを与えること。コミットメッセージやPRの説明、issueを含む、あらゆるユーザー入力はLLMに渡される前に検証されるべきであること。そして、緊急時のキルスイッチを用意しておくことです」と同氏は述べています。「ほとんどのチームは、侵害されたAPIキーを無効化できるでしょう。では、暴走したエージェントを無効化できるでしょうか」
Dubey氏は、GitLostは、AIエージェントが組織内で広範なアクセス権を与えられると、事実上インサイダー脅威になり得るということを示していると述べています。
「GitLostの巧妙さは、AIを騙したという点にあるのではありません。GitHubが『サービスアカウントは信頼できる』という前提を武器に変えてしまったという点にあるのです」と同氏は述べています。「エージェントは、人間の判断を迂回して自律的に動作するよう、まさにそのために作られたものです。だからこそ危険なのです。私たちは、それを自動化した瞬間に、境界を越えた操作を当たり前のものにしてしまったのです」Nomaはまた、最小権限のアクセス制御を適用すること、AIエージェントによる複数リポジトリ間のアクセスを制限すること、そしてGitHubのIssue、プルリクエスト、コメントを信頼できない入力として扱うことを推奨しています。
