セキュリティ
汚染されたプルリクエストにプロンプトインジェクションを仕込み、一方のAIエージェントがもう一方を制御
あるAIエージェントを使って、より高い権限を持つ別のAIエージェントを制御し、侵害できることが明らかになりました。Pillar Securityの研究者は、これを「史上初の実環境におけるエージェント間攻撃」の手法だとし、Googleが提供するAgent Development Kit for Pythonのリポジトリに、攻撃者がサプライチェーンを侵害しうる欠陥を発見したと報告しています。
この問題は、AIエージェントの構築・展開に使われるオープンソースのPythonツールキットで9,000万回以上のダウンロードを記録しているgoogle/adk-pythonに存在していました。
Googleはリポジトリ側の根本的な問題を既に修正していますが、この攻撃はソーシャルエンジニアリングを伴うものであるとして、報奨金の対象外と判断しました。とはいえ、この事例は、CI/CDワークフローにおけるトリアージやプルリクエスト(PR)レビュー、議論の場でAIエージェントを利用することに伴うリスクを浮き彫りにしています。
この脆弱性を発見し報告したPillarのDan Lisichkin氏によれば、今回の事例は、本番環境において一方のAIエージェントがもう一方を攻撃しうることも示しているといいます。
「私たちを取り巻く世界は急速に変化していますが、新たな攻撃対象領域は脅威モデルにまだ十分反映されていません。こうした攻撃は『エージェント以前』の世界ではそもそも存在し得なかったからです」。Lisichkin氏は月曜日に公開した技術解説記事の中でこう述べています。同氏は8月7日(金)16:00(PDT)に、DEF CONのAI Villageで行われるポスターセッションでもこの調査結果について発表する予定です。
Lisichkin氏は「CISOやセキュリティ担当者は、こうしたシナリオを検討し始め、脅威モデル化を行い、最悪のケースで生じうる影響と被害範囲を計算しておくべきです」と記しています。
問題の根本原因は、このリポジトリが権限レベルの異なる2種類の自動AIエージェントを稼働させており、それらが意図せず信頼境界を共有していたことにあります。一つは、ユーザーがプルリクエスト(PR)やIssueを開くたびに起動する、低権限で外部公開されたAIエージェント。もう一つは、メンテナー専用の高権限エージェントです。
Pillarのチームは、低権限で外部公開されているエージェントをプロンプトインジェクションによって操作し、悪意ある操作を実行できるメンテナー専用エージェントを呼び出させることが可能だと突き止めました。
Lisichkin氏は「これらのエージェントが裏側でどのように動作するかを説明するワークフローも公開されているため、一方のエージェントが、少なくとも理論上は、もう一方のエージェントを『呼び出せる』はずだと、誰でも点と点をつなげられる状態でした」とThe Registerに語りました。「攻撃を組み立てる際に必要なのは英語の知識だけです。プロンプトインジェクションを作成できます(あるいは単にAIに作らせることもできます)」。
ただし一つ注意点があります。攻撃者はプロンプトインジェクションに移る前に、まずリポジトリに正当な貢献を行い、メンテナーからの信頼を築く必要がある可能性が高いという点です。
しかし、それだけの時間をかける意思がある攻撃者を想定すると、攻撃は次のように展開します。
まず、外部ユーザー(すなわち攻撃者)が新しいPRを作成します。Lisichkin氏はこれをPR Aと呼んでおり、このPRには正当な修正内容と、変更されたpackage.jsonや悪意あるディペンデンシーといった悪意あるコードが組み合わされています。
続いて、高権限のコラボレーター用個人アクセストークン(PAT)に紐づいた、外部公開されているエージェントが攻撃者のPR本文を読み取り、そのPRをレビュー対象としてマークします。このコラボレーターPATによる信頼レベルにより、攻撃者が生成したテキストが、ゲート付きワークフローを起動させることが可能になります。
PR Aのトリアージが行われた後、攻撃者はプロンプトインジェクションを仕込んだ2つ目のPR(PR B)を開きます。すると、トリアージエージェントが信頼された@gemini-cliへのハンドオフを発行します。これにより権限を持つエージェントのワークフローが起動し、悪意ある操作が実行されてしまいます。
Lisichkin氏は「これらを組み合わせることで、『人間がレビューを依頼し、geminiがそれを実行し、geminiが承認した』という、一見信頼できるが実際には一度も起きていない完全な経緯が、汚染されたPR上ででっち上げられます」と記しています。
GoogleはThe Registerの問い合わせに応じませんでしたが、Lisichkin氏は根本的な問題が修正されたことを確認しています。それでもGoogleは、今回の調査結果はバグ報奨金の支払い基準を「満たさなかった」としています。
Googleは次のように説明しています。「この報告は、’pull-requests: write’権限を持つGitHubトークンの窃取を示すものであり、これによりPRの改ざんが可能になります。しかし、PRはボットによるレビュー後に自動でマージされるわけではないため、悪意あるPRをマージするにはメンテナーによる操作が依然として必要です」。
その理由についてはさらにこう続けています。「サプライチェーンのセキュリティ侵害を可能にするためにソーシャルエンジニアリングを必要とする脆弱性報告に対しては、報奨金を支払っていません」「とはいえ、私たちはリポジトリを強化する対応を行っており、この報告についてはクレジットとして認定します」。
Lisichkin氏は、今回の調査結果はエージェントの分離だけでは不十分であることを示していると私たちに語りました。
同氏は「エージェントは、どのリソースへのアクセスが許可され、それらのリソースとどのようなやり取りが許可されているかを規定する、独自のアイデンティティを持つべきです」と述べています。「今回のケースでは、Googleが最初のトリアージエージェントにボットとしてのアイデンティティを与えてさえいれば、攻撃の大部分は防げていたはずです。セキュリティチームは、エージェントのアイデンティティとエージェントによるリソースアクセスを、自社の脅威モデルの中でモデル化し始める必要があります」。®
