8月4日、Cybersecurity Newsが「A Malicious GitHub Issue Could Turn Google's AI Agent Against Its Own CI/CD Pipeline」と題した記事を公開した。GitHubにIssueを一つ開くだけで——特権アクセスも不要で——GoogleのAIエージェントが自身のCI/CDパイプラインを攻撃し、機密シークレットを流出させられる。セキュリティ企業Pillar Securityが実証したこの脆弱性は、AIエージェントをパイプラインに組み込む際の根本的な設計上の盲点を突くものだ。
GitHubのIssueを起点に、AIエージェントが自身のパイプラインを攻撃する
Pillar Securityの研究者が標的にしたのは、google/adk-pythonリポジトリだ。ADK(Agent Development Kit)はGoogleが提供するAIエージェント構築フレームワークで、複数のエージェントが連携して動作する「マルチエージェントシステム」の開発を想定して設計されている。このリポジトリ自体が、ADKを使ったマルチエージェントワークフローで運用されていた。
マルチエージェントCIとは、PRのトリアージ・コードレビュー・デプロイ承認といった従来は人間が担っていた工程を、複数のAIエージェントが分担して処理する仕組みだ。GitHubリポジトリとの連携が深く、エージェントがコメント投稿・ワークフロートリガー・コードレビューなどのアクションを自律的に実行する。このアーキテクチャにおいて研究者が実証したのが、エージェントが別のエージェントを攻撃するという新しい攻撃クラスだ。
このリポジトリは2層構造のAIエージェントで運用されていた。
- 低権限エージェント(adk_pr_triaging_agent):外部ユーザーがPRやIssueを開いた際に起動する、公開向けの処理担当
- 高権限エージェント:信頼されたメンテナー専用で、コードベースへの実質的な権限を持つ
問題は、この低権限エージェントがスコープ付きのBot IDではなく、人間のコラボレーターアカウントに紐付けられていた点にある。
攻撃の連鎖:PRコメントからフェイク承認トレイルまで
研究者は、PRコメントを正規の貢献メモに偽装することで、低権限エージェント(adk_pr_triaging_agent)に@gemini-cliで始まるコメントを投稿させることに成功した。これにより、高権限のgemini-invokeおよびgemini-reviewワークフローがトリガーされた。
エージェントが実在のコラボレーターアカウントでコメントしているため、GitHubはそのトリガーを「信頼された人間からの操作」として扱う。
抽出されたGitHubトークンは、IssueおよびPRへの書き込み権限のみに限定されたスコープだったが、それでも以下が可能だった:
- 他ユーザーのコメントの編集
- メンテナーへのなりすまし
- 「approved」マーカーを表示する偽の自動コードレビューのトリガー
これらを組み合わせることで、悪意あるPRに対して人間が一度もレビューしていないにもかかわらず、完全に信頼できる承認トレイルを捏造できてしまう。

攻撃チェーン(出典:Pillar Security)
修正後に追加されたコードが、さらに深刻な脆弱性を生んだ
初回開示の数日後、Googleは同リポジトリに新たな自動化コードを追加した。これはAntigravity SDKベースの実装だ(※AntigravityはGoogleが開発した内部向けCI自動化ライブラリで、ADKと組み合わせてエージェントのワークフロー制御に用いられる)。この追加が新たな問題を引き起こした。
安全なgit・ghコマンドのみに限定するためのコマンドallowlistが、gitのスクリプト機能(フックやシェルエイリアス)を使うことでバイパス可能だった。これにより、CIランナー上でリモートコード実行が事実上可能になった。
CIランナーには長期有効なPersonal Access Token(PAT)とGoogle Cloudのサービスアカウント認証情報が格納されていたため、GitHubのIssueを開くだけ(特権アクセス不要)で、パイプラインから機密シークレットを窃取できる状態だった。
Googleの対応と報奨金の判断
Googleはこの報告を確認し、adk-pythonリポジトリを強化した。ただし、「メンテナーが悪意あるコードをマージするという人間のアクションが依然として技術的に必要」という理由から、ソーシャルエンジニアリングに依存するサプライチェーンシナリオはバグバウンティの対象外と判断した。Pillar Securityは報告に対して特別表彰を受けるにとどまった。
AIエージェント時代の新しい脅威モデル
この事例が示す教訓は、従来の脅威モデルがエージェント型AIワークフローを想定していないという点だ。
IssueやPR、サポートチケットといった信頼されていないテキストを取り込みながら、認証情報を保持するAIエージェントは、攻撃者が制御可能なエンティティとして扱う必要がある。
研究者が推奨する対策は以下の通りだ:
- エージェントにはPATではなく、スコープを絞った監査可能なBot IDを割り当てる
- 厳格なツールallowlistを適用する
- ブランチ保護や必須コードレビューなど、人間によるガードレールを維持し、単一エージェントの侵害がサプライチェーン全体に波及しないようにする
AIエージェントをCI/CDパイプラインに組み込む動きが広がる中、この攻撃クラスはエンジニアリングチームとセキュリティチームが今すぐ向き合うべき問題だ。
詳細はA Malicious GitHub Issue Could Turn Google's AI Agent Against Its Own CI/CD Pipelineを参照していただきたい。




