AIDEFEND in Action AIA-0090 實證研究 發布於 AIA: 2026年10月1日

Google ADK 儲存庫：以公開 PR 提示詞誘導 agent 跨邊界觸發高權限 CI 流程

Google ADK（Agent Development Kit）是開發 AI agent 的開源框架。Pillar Security 研究發現，攻擊者可在公開 Pull Request（PR）說明中植入惡意指示，誘導處理公開輸入的分類 agent 以具備協作者身分的帳號張貼特定留言；後端派工流程誤將該留言視為有效授權，進而啟動高權限的 Gemini 審查工作流程。研究者在受控測試環境中重現了 agent 間的權限越界交接，並展示後續憑證外洩與竄改 PR 審查訊號的風險；公開資料顯示並無惡意 PR 實際遭合併。Google 隨後已強化該儲存庫的防護機制。

Indirect Prompt InjectionTool AuthorizationA2A SecurityGitHub Security
5 項對應的 AIDEFEND 防禦手法
來源: I'll Just Call You: Agent-to-Agent Privilege Boundary Failures in CI/CD on Google's ADK Repository 
作者: Dan (danusminimus)
原文發布: 2026年8月3日

威脅分析

低信任的外部 PR 之所以能升級為高權限的 CI 工作流程請求，關鍵在於分類 agent 使用具備協作者權限的機器人帳號留言。接收端的 Gemini 派工流程只檢查留言帳號的協作者身分，沒有查明真正發起請求的是誰，也沒有確認審查權限是否經過授權委派。

  1. 攻擊者在公開 PR 說明中加入提示詞，將首行帶有 @gemini-cli 的留言偽裝成儲存庫正常的分類交接程序。
  2. 公開分類 agent 讀取不可信的 PR 內容後順從指示，透過具有協作者身分的 adk-bot 帳號在 PR 內張貼該留言。
  3. 派工工作流程（gemini-dispatch）偵測到協作者發出指令，未經獨立驗證真實請求來源或委派任務，便逕行轉發給高權限的 gemini-invoke 流程。
  4. Gemini agent 在權限較高的 CI 工作流程中接收到攻擊者構造的提示詞；該工作流程可使用的憑證與 PR 審查操作，比公開分類流程更多。研究者成功驗證此一跨 agent 交接機制，並在該工作流程實際擁有的權限範圍內，分析讀取憑證與操作 PR 審查的可行性。
  5. 研究者進一步完成了修改審查留言、標籤與 PR 核准訊號的概念驗證（PoC）；但最終合併 PR 仍需儲存庫維護者人工核准，目前並無惡意程式碼遭合併的公開報告。

研究者已在受控測試環境中重現此跨 agent 觸發路徑，並驗證了憑證洩漏與竄改審查訊號的潛在衝擊。依現有公開證據，合併 PR 仍需維護者手動操作，Google 亦已針對該儲存庫進行安全強化，目前沒有公開證據顯示惡意 PR 已經合併或進入正式發布版本。

適用的 5 項 AIDEFEND 防禦手法

AID-H-004.003
Secure Agent-to-Agent Communication
極高
gemini-dispatch 啟動高權限工作前，必須從綁定本次請求的可信紀錄驗證原始發起者、核准任務與不得擴張的委派範圍。GitHub 事件能辨識留言者，不能單獨證明原始請求者或已核准的委派鏈；協作者 PAT 或自動化留言本身均不足以授權高權限執行。
AID-H-018.002
Policy-Based Access Control
高
在通往 GitHub 的唯一工具配接器上，依已驗證的任務身分核對確切儲存庫、PR 與審查動作。一般審查可以留言，但未另行取得任務授權時，不得核准 PR、撤銷審查或變更會影響授權的標籤；也須移除能繞過此判定的 shell 與直接 API 路徑。另外應停用 Actions 建立或核准 PR 的權限、限縮實際生效的工作 token 權限，並要求真人 Code Owner 審查。這些平台設定可補強配接器的授權檢查；這裡討論的是 PR 操作授權，與 AID-H-023 的套件發布控制不同。儲存庫範圍的 token 並不等於單一 PR 的授權，配接器仍須核對確切任務與目標。
AID-H-017.002
Least-Privilege Tool Architecture
高
為高權限的 Gemini 作業建立嚴格的 tools.core 允許清單，僅註冊任務真正需要的具型別 PR 審查專用工具。若 Gemini agent 沒有可呼叫的 shell 工具，就無法透過這條路徑讀取環境變數中的 GITHUB_TOKEN，或繞過 MCP 工具直接呼叫 GitHub API。這可切斷研究者示範的 shell 竊取 token 路徑；仍須確認沒有其他可繞過工具清單的執行方式。
AID-M-009.003
Agent Identity, Delegation Lineage & Authorization Context
中
若工作流程設計採用 agent 間委派（A2A delegation），應建立由授權人類審查請求發起、經分類 agent 延伸至派工流程的可驗證數位簽章委派鏈。鏈結中的每一環節均須綁定工作負載身分（workload identity）、限定任務、有效期限與不得逾越的權限範圍；接收端 agent 必須在完整驗證此委派鏈後，方可將留言解析為操作請求。一般的 GitHub 留言或協作者 PAT 完全缺乏此類委派脈絡，需透過專門的委派服務實作，無法依賴儲存庫現有的作者身分檢查。
AID-D-011.004
Non-Human Identity & Delegated Token Abuse Detection
中
在 GitHub Enterprise 稽核串流（Audit Log Streaming）或等效事件來源具備相應能見度的情境下，應即時關聯機器人帳號的 PR 核准或駁回操作與經授權的工作流程紀錄，若執行 PR 審查的身分或操作範圍未獲核准，就發出警示通知。在仰賴偵測機制前，須先驗證事件涵蓋範圍與日誌延遲時間；單看留言或標籤紀錄，無法知道實際是哪一把 token 執行了操作。

身為資安防禦者，我們應該這麼做

  • 為自動化流程配置專屬且權限最小化的機器人身分：切勿讓處理不可信公開輸入的 agent 共用具備專案協作者權限的個人存取 token。
  • 落實跨 agent 呼叫的獨立來源驗證：在每次由留言或事件觸發後續高權限流程時，接收端皆須獨立核驗原始發起者身分、委派任務與允許權限，不可單憑留言帳號角色放行。
  • 嚴格限制工具配接器的操作範疇：將接收端 agent 的工具呼叫能力嚴格限制在當前 PR 與具體任務內；保留獨立的分支保護與真人 Code Owner 審查；機器人產生的核准訊號不能取代維護者的合併審查。

1 個額外的防禦考量

證據與部署界線

原始研究報告中另提及一條由 issue-analyze 延伸至 issue-fix 的不同路徑。本案例 SecureFlow 與分析聚焦於「PR 分類 agent 跨界觸發 Gemini 派工」這條核心攻擊鏈，並未將兩套獨立的工作流程混淆為單一因果關係。
建議做法: 為自動化流程配置專屬且權限最小化的機器人（Bot）身分，切勿讓處理不可信公開輸入的 agent 共用具備專案協作者權限的個人存取 token。

結論

AIDEFEND  在本案指出兩個防禦落點：接收端 agent 須從可信紀錄確認原始請求者與已核准的委派範圍；工具配接器則須逐次核對目標 PR 和允許的審查動作。不能只因留言帳號具有協作者身分，就讓後續流程執行高權限操作。

最後更新: