Google ADK agent 越權鏈曝光：兩個隔離 AI 點樣互相借權
低權限 triage agent 可叫醒高權限審查 agent，Google 已加固 repository
AI coding agent 擺入 GitHub Actions，最易令人放心嗰句通常係「兩個 agent 已經分開權限」。今次 Google ADK Python repository 出現嘅研究案例，正正拆穿呢份安全感：兩邊雖然各自運行，低權限 agent 留低嘅一句留言，仍然可以俾另一套自動化當成可信指令，跟住用較高權限做事。
低權限 agent 點樣借到另一邊把刀
TechNews 科技新報報道，Pillar Security 研究員 Dan Lisichkin 喺 google/adk-python 發現兩類 AI 自動化。其中對外開放嗰邊負責處理外來 PR，可以讀內容、加標籤同留言；另一邊只預畀 collaborator 或 maintainer 用，收到指定格式嘅 @gemini-cli 留言，就會啟動 Gemini 審查或執行指令。
表面睇，入口已有身份檢查。不過公開 triage agent 用嘅 adk-bot 原來係帶 collaborator 身份嘅普通帳戶，再配上一個 personal access token（PAT），唔係權限獨立嘅 GitHub App。研究員將惡意 prompt 包裝成符合 contribution 指引嘅 triage 步驟，令呢個 agent 主動貼出 @gemini-cli 指令。下游自動化見到留言來自 collaborator，就當成可信交接，較高權限 agent 隨即俾人叫醒。
兩個 process 有冇隔離，其實只處理咗一半風險。 只要低權限 agent 可以產生下游信任嘅留言、標籤或事件，嗰啲輸出就等同一張通行證。傳統權限檢查只見到「邊個帳戶留言」，睇唔到背後係 maintainer 親手輸入，抑或公開 agent 食咗外來 prompt 後代為發出。
圖片：Pillar Security
GitHub token 冇 main 寫入權，都可以整假審批紀錄
Pillar 嘅測試顯示，高權限 agent 所在環境帶有 issues: write 同 pull-requests: write 嘅 GitHub token。呢組權限唔足以直接推 code 入 main，但可以改 issue 或 PR 留言、提交 PR review、撤銷 review request，同埋轉換標籤。研究員據此設計咗雙 PR 情境：一個 PR 藏住有問題嘅改動，另一個 PR 就負責 prompt injection，再操控前者嘅審查紀錄。
攻擊者可以改寫 triager 留言，扮成對方要求 Gemini 審查；跟住由 github-actions[bot] 留下開始處理同審批訊號，再移走原有 reviewer request。畫面上會出現一條幾完整嘅人類交接、AI 審查同批准紀錄。GitHub token 嘅危險程度唔可以單靠 contents: write 判斷，改留言同 review 狀態已經足以影響 maintainer 判斷。
不過呢度要收窄講法。Pillar 將事件形容為首個實際 agent 對 agent 攻擊案例，呢個係研究機構自己嘅定性，暫時未見 CVE 或獨立業界標準確認。研究亦針對 Google 自家 ADK repository 嘅 GitHub 自動化設定，唔代表安裝 ADK Python 套件嘅項目會自動出現同一條攻擊路徑，更唔等於所有 ADK app 都可俾外人直接入侵。
Google 有修補，但最後一關原本仍靠人
Pillar 公開嘅 Google 回覆指，受影響流程用到嘅 token 只可改動 PR，惡意改動仍要 maintainer 親手合併；Google 所以將情境視作要配合社交工程，未達漏洞獎金門檻，不過有加固 repository 同列入鳴謝。公開 commit 亦顯示，Google 其後移除會讀取外來 issue 或 PR、又帶較廣權限嘅幾套 agent 自動化，等候較安全嘅重新設計。
人工 merge gate 今次的確壓低咗最壞影響，但前提係 maintainer 會重新核實每個訊號。當 PR 頁面已有 bot 審查、批准字眼、正確標籤同貌似由同事留下嘅留言，趕住清 backlog 嘅人好容易順手撳 merge。Branch protection 同指定真人 reviewer 都要設定成硬規則，亦要禁止用 bot approval 代替真人審批，唔可以淨係靠團隊習慣。
部署 coding agent 前，四道防線要分清
每個 agent 都應該有獨立 GitHub App 或短效 token，唔好共用真人帳戶、長效 PAT 或 collaborator 身份。公開 triage agent 只攞讀取同必要留言權限，亦唔應接觸部署 secret、雲端憑證或可改審批狀態嘅 token。GitHub 官方安全指引同樣建議預設只讀，再按每個 job 最少量加權限。
Agent 之間嘅交接亦要重新驗證。下游高權限 job 唔可以只見到指定字句同 collaborator 帳戶就開工；應核對最初發起者、事件來源同不可由 agent 偽造嘅人工批准。高風險操作可以放入受保護 environment，等 required reviewer 放行，runner、cache 同 secret 範圍亦要分開。最後保留完整 audit log，清楚記低邊個 agent、用邊個 token、因咩事件執行過咩動作。
開發團隊而家最值得檢查嘅，係所有由 PR、issue、留言、ticket 或電郵自動觸發嘅 coding agent。逐條追返身份、token、交接訊號同最終合併權，通常就會見到原先冇畫入權限圖嘅路徑。
參考來源
- TechNews 科技新報 — 首見「AI 互駭」！Google 開發套件曝漏洞，揭露代理對代理攻擊風險 — original report
- Pillar Security：Agent-to-Agent Privilege Boundary Failures — 研究員一手披露，詳列 prompt injection、身份交接、token 權限、攻擊情境同披露時間線。
- Google ADK Python 舊版 PR triage 設定 — 公開原始設定顯示觸發條件、PR 寫入權限、adk-bot token 同外來 PR 處理方式。
- Google ADK Python 修補 commit 66730e9 — Google 公開紀錄，確認移除會處理外來 issue 或 PR 並持有較廣憑證嘅 agent 自動化。
- GitHub Actions Secure Use Reference — GitHub 官方對最小 token 權限、environment reviewer、secret 管理同外來 PR 觸發風險嘅建議。
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
