Google ADK repository 權限穿透：低權限 bot 點借身份改 PR
研究示範由公開 PR 文字一路踩入高權限自動化
iThome 報道，Pillar Security 喺 Google ADK for Python 嘅 GitHub repository 發現一條 agent-to-agent 攻擊鏈：外來開發者只要控制 PR 或 issue 入面嘅文字，就有機會先影響公開使用嘅低權限 agent，再叫佢觸發只預留畀 maintainer 嘅高權限自動化。今次中招嘅位置係 repository 本身嘅 GitHub Actions 設計，唔代表 ADK framework、Gemini 模型或者其他 Gemini 產品都有同一漏洞。
一段 PR 文字點樣跨過權限閘
Pillar 嘅第一個示範由 PR triage agent 開始。呢個 agent 會讀取外來 PR，再留言同加 label。研究人員將惡意 prompt 包裝成正常嘅 repository 指引，誘使 agent 留下一段以 @gemini-cli 開頭嘅留言。關鍵係呢個 agent 用個人 access token 操作，GitHub 見到嘅留言者係擁有 collaborator 身份嘅普通帳戶，唔係權限受限又容易辨認嘅 GitHub App。
另一個 gemini-dispatch workflow 只檢查留言者係咪 owner、member 或 collaborator，同埋留言有冇指定指令。當低權限 agent 借 collaborator 身份出聲，呢兩個條件就一齊過關，跟住啟動 gemini-invoke 或 review agent。路由器只見到一個可信身份，但冇再查清楚條指令原來係由外人控制嘅 PR 傳入嚟。結果係外來內容借住可信帳戶過關，直接觸發高權限 agent。
圖片：Pillar Security
PR 寫入權限一樣可以搞亂審批紀錄
第一條攻擊鏈攞到嘅 GITHUB_TOKEN 只有 issues: write 同 pull-requests: write，研究資料冇顯示佢可以直接 push 程式碼入 main。不過呢啲權限仍可改動或刪除留言、提交假 review、撤走 review request，亦可營造一條似由自動化帳戶完成審批嘅紀錄。要真係 merge 到惡意程式碼入 repository，仍然要呃過 maintainer 或其他內部關卡。所以呢次係研究人員示範嘅攻擊路徑，唔係已證實嘅大規模供應鏈入侵。
Pillar 亦披露咗另一條涉及 Antigravity-based issue 修復 agent 嘅鏈。公開 issue 可影響分析 agent，叫佢用 collaborator 帳戶留下 /adk-issue-fix，繼而啟動持有更多憑證嘅修復 agent。呢個 agent 嘅指令限制只容許 git 同 gh，但 git 本身已有方法啟動其他程式，加上 agent 可以寫檔，研究人員喺示範環境做到 runner remote code execution，令個人 access token、Google API key 同 GCP service account key 面對外洩風險。相關 token 同 service account 實際權限冇公開資料可以完全確認。
圖片：Pillar Security
Google 已移除相關自動化
Pillar 嘅披露時間線顯示，兩份報告分別喺 2026 年 6 月 2 日同 6 月 5 日交畀 Google。Google 喺 7 月表示 repository 已加固，亦指出 maintainer merge、社交工程要求同內部 Copybara 匯入審查會限制實際影響。公開 commit 顯示，Google 刪除 issue-analyze、issue-fix 同 pr-analyze 三個 workflow，commit 說明亦直接提到佢哋會用廣泛 repository 憑證處理不可信 issue 同 PR 內容。Pillar 話 Google 喺 7 月 21 日確認第二項問題已修正。
權限要跟身份、來源同每次動作分隔
用 Gemini、ADK 或其他框架砌多代理系統，第一步係將每個 agent 當成獨立 service identity。公開 triage agent 唔應共用 maintainer 帳戶或長期個人 token；要留言就用短效 GitHub App token，權限收窄至指定 repository 同指定動作。讀取 PR、修改 PR、提交 review、存取 secret、寫入程式碼同操作雲端資源，都應拆開憑證，亦唔好將全部 secret 放入同一個 runner environment。
高權限 workflow 嘅入口亦要改。自然語言留言、另一個 agent 嘅輸出，同任何由外來文件整理出嚟嘅內容都唔應直接當成授權訊號。真正跨權限嘅動作可要求獨立人手確認、由受控介面產生嘅結構化事件，或者經政策層重新核對原始操作者同資料來源。Google ADK 官方安全指引同樣建議用 agent auth、最小權限、tool guardrail、callback、追蹤同網絡限制收細影響範圍。用開 agent 自動處理 issue、PR、電郵或支援 ticket 嘅團隊，而家最值得做嘅係畫清楚每次 agent hand-off 帶住邊個身份、邊粒 token，同埋下一步究竟可以改到咩。
參考來源
- iThome — 研究人員揭露Gemini AI代理對代理攻擊手法，可竊取敏感資料並竄改GitHub拉取請求 — original report
- Pillar Security：Agent-to-Agent Privilege Boundary Failures — 研究原文，交代兩條攻擊鏈、權限限制、示範環境同披露時間線
- Google adk-python 修正 commit 66730e9 — 確認 Google 刪除會用廣泛憑證處理不可信內容嘅三個 agent workflow
- Google ADK：Safety and Security for AI Agents — 官方身份授權、最小權限、tool guardrail、追蹤同網絡限制建議
- Google adk-python：受影響時期嘅 gemini-dispatch workflow — 核對 collaborator 身份檢查、@gemini-cli 路由條件同 PR 寫入權限
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
