今回の欠陥は、エージェント型ワークフローが信頼済みリポジトリのシグナルを権限昇格の経路へと変えてしまう仕組みを浮き彫りにしています。従来のIDおよびCI/CD管理では見抜けない可能性のある問題です。
GoogleのAgent Development Kit for Python向けGitHubリポジトリにおける自動化ワークフローのセキュリティ上の欠陥により、一般公開されているAIエージェントがより高い権限を持つ自動化処理を引き起こせる可能性があったことが、Pillar Securityのレポートで明らかになりました。攻撃経路の一つはプルリクエストのレビューを操作するもので、もう一つは認証情報を漏洩させるものでした。
1つ目の攻撃経路は、外部の協力者から提出されたプルリクエストを解析するトリアージエージェントに関するものです。このエージェントは、リポジトリへのコラボレーターアクセス権を持つadk-botというアカウントを通じて応答を投稿していました。Pillarの調査によると、プルリクエストに悪意ある指示を埋め込むことで、このエージェントに「@gemini-cli」コマンドを投稿させ、本来は信頼されたユーザー向けに用意されたワークフローを起動させることが可能だったといいます。
このワークフローは、CIランナー内でコマンドを実行できる状態を生み出す可能性がありました。使用されるGitHubトークンにコードのプッシュ権限はなかったものの、issueやプルリクエストへの書き込み権限は備えていました。Pillarによれば、この権限を悪用すれば、メンテナーのコメントを改ざんしたり、github-actions[bot]として承認レビューを投稿したり、正規のレビュー依頼を削除したりすることが可能で、悪意あるプルリクエストをマージ可能な状態に見せかけられるとのことです。
Pillarは自社の調査環境で、この1つ目の攻撃チェーンの再現に成功しました。マージを完了させるにはメンテナーの操作が依然として必要でしたが、レポートによるとGoogleはその後、このリポジトリの防御を強化したとのことです。
同セキュリティ企業は、Antigravityベースのエージェントを中心に構築された新しいワークフロー群でも、別の攻撃経路を発見しました。攻撃者は公開issue内にプロンプトインジェクションを仕込むことで、解析エージェントに対し、信頼されたリポジトリユーザー専用の修正ワークフローを起動するコマンドを投稿させることができました。
この修正ワークフローは、エージェントの操作をGitおよびGitHubのコマンドのみに制限しようとしていました。しかしPillarの調査により、Gitを使って任意のコードを実行できることが判明しました。研究者らは、adk-botの個人アクセストークンをランナーから攻撃者が管理するサーバーへ抽出できることを実証したほか、Google Cloudのサービスアカウントキーもこのワークフローから利用可能な状態であったことを確認しています。
Pillarによると、7月2日の時点で該当するワークフローが削除されたことを確認しており、Googleは7月21日、2つ目の問題も修正済みであると研究者らに伝えたということです。
エージェント間の引き継ぎが露呈するリスク
Pillarはこの発見について、本番稼働中のマルチエージェントシステムを対象とした「エージェント間エクスプロイトの実例としては初の、実践的かつ現実世界における事例」と説明しています。
Greyhound ResearchのチーフアナリストであるSanchit Vir Gogia氏は、根底にある脆弱性自体はよく知られたものだが、それらが組み合わさることで、企業はエージェント型システム内で権限がどのように移動するかを見直す必要に迫られていると述べています。
「自然言語が認可経路の一部に組み込まれてしまったのです」とGogia氏は述べています。「報告に値する変化はそこにあるのであって、『史上初』という枕詞ではありません」
Gogia氏によれば、あるエージェントの権限は、それに割り当てられたツールだけでなく、その出力が引き起こしたり影響を及ぼしたりできる、より高権限のシステムまで含めて評価されるべきだといいます。
IDC Asia Pacific Cybersecurity ServicesのシニアリサーチマネージャーであるSakshi Grover氏によれば、こうした波及範囲の広さは、CISOがこのリスクの深刻度を判断する上での基準にもなるべきだといいます。
「CISOにとって重要性の判断は、次の3点を追跡することで決まるはずです」とGrover氏は述べています。「第一に、プルリクエスト、issue、メール、サポートチケット、外部ドキュメントといった信頼できないコンテンツを取り込むエージェントはどれか。第二に、それらのエージェントの出力が、直接的または間接的に、より高い権限を持つ別のエージェントやワークフローを起動できるか。第三に、関係するID、認証情報、ツールが持つ実効的な能力の上限はどこまでか、という点です」
推移的な権限の可視化
既存のセキュリティツールでは、エージェントとワークフローの間で権限がどのように移動するかについて、部分的な把握しかできない場合があります。
Grover氏によれば、IAM、PAM、CIEM、そしてアプリケーションセキュリティ関連のツールは、個々のIDや権限、安全でないワークフロー構成を可視化できるものの、それらの構成要素が一つのイベント駆動型の権限委譲経路を形成していることまでは認識できない場合があるといいます。
「インベントリが記録するのは『何が存在するか』であるのに対し、権限委譲のマッピングが記録するのは『何が起こり得るか』です」とGogia氏は述べています。
Gogia氏はさらに、セキュリティチームは、外部からの入力がエージェントに到達した時点から、その結果を基に動作する下流のシステムに至るまでを追跡すべきだと付け加えています。レビューでは、あるコメントがコマンドを引き起こすといった、共有ワークフロー状態に埋め込まれた引き継ぎについても考慮する必要があります。
「より難しい問いは、エージェントAがエージェントBを呼び出せるかどうかではなく、エージェントAがエージェントBの既存の信頼対象を書き換えられるかどうかです」と同氏は述べています。
人間による承認があっても、必ずしもこのギャップが埋まるわけではありません。1つ目の攻撃経路では、プルリクエストをマージするにはメンテナーの操作が依然として必要でしたが、操作された自動化処理がメンテナーに提示される証拠そのものに影響を及ぼしうる状態でした。
「他人にマージさせるための証拠を捏造できるのであれば、攻撃者自身にマージ権限は不要です」とGogia氏は述べています。同氏はさらに、承認は独立して認証されたレビュアーが、実際に検証したコードや成果物そのものに紐づけられるべきであり、重要な変更が加われば、その承認は無効化されるべきだと付け加えています。
Grover氏はまた、レビュー、コメント、承認状態への変更もセキュリティイベントとして扱い、そのワークフロー自身のIDでは改ざんできない独立したログシステムへ出力すべきだと述べています。
