三層防御仍然不夠，一條PR標題就能偷走你的API密鑰：AI Agent安全裂痕再現(xiàn)

獨立安全研究員關傲男（Aonan Guan ）聯(lián)合約翰霍普金斯大學博士生研究員劉征宇、鐘佳成，近期公開發(fā)布了一項跨越三家科技巨頭的AI Agent安全研究成果。

研究證實，Anthropic的Claude Code安全審查工具、Google的Gemini CLI GitHub Action，以及微軟GitHub旗下的Copilot Agent，均存在同一類被研究者命名為「評論與控制」（Comment and Control）的漏洞模式——攻擊者僅需通過Pull Request標題、Issue評論或隱藏HTML注釋，即可劫持這些AI Agent，竊取宿主倉庫的API密鑰和訪問令牌。

這是首次有研究團隊在跨廠商范圍內系統(tǒng)性演示這一攻擊模式。三家公司均已確認漏洞存在并進行了修復，但截至發(fā)稿，均未向用戶發(fā)布正式的安全通告。

一條PR標題引發(fā)的安全鏈式反應

所有故事的起點都指向同一個結構性缺陷：AI Agent在執(zhí)行任務時，會讀取倉庫中外部貢獻者提交的內容并將其作為指令依據(jù)，但并未對這些輸入建立有效的隔離與校驗機制。

Anthropic的Claude Code安全審查工具是最早被攻破的案例。這款運行在GitHub Actions中的AI安全Agent，旨在自動審查Pull Request中的代碼變更，曾被Anthropic作為旗艦功能重點推廣。Aonan Guan在審查其源代碼時發(fā)現(xiàn)，PR標題被直接拼接到提示詞模板中，未經(jīng)過任何過濾或轉義。與此同時，Claude CLI在調用時未啟用工具權限限制參數(shù)，子進程完整繼承了宿主環(huán)境的所有環(huán)境變量。

攻擊效果是直接的：攻擊者只需創(chuàng)建一個PR，在標題中嵌入精心構造的注入文本，即可突破Claude的提示詞邊界，指示其執(zhí)行任意系統(tǒng)命令——包括讀取 ANTHROPIC_API_KEY 和 GITHUB_TOKEN 等敏感憑證。Claude會將命令執(zhí)行結果寫入 JSON 響應，隨后自動發(fā)布為PR評論。攻擊者無需任何特殊權限，開一個PR即可完成竊取。

Claude Code在PR評論中泄露Anthropic API密鑰的截圖

在驗證了Claude Code之后，研究團隊將目標轉向Google的Gemini CLI GitHub Action，攻擊邏輯如出一轍。攻擊者創(chuàng)建一個帶有注入標題的Issue，隨后在評論中逐步升級注入指令——先要求Gemini關注用戶任務，再偽造一個「可信內容區(qū)」，聲稱當前環(huán)境安全，允許共享 GEMINI_API_KEY 等令牌。這一策略成功覆蓋了Gemini原有的安全指令，導致其將完整API密鑰以Issue評論的形式公開暴露。

兩家廠商在披露過程中的處理方式存在差異。Anthropic于2025年10月收到報告后，將漏洞評級提升至CVSS 9.4（Critical級別），并將報告從公開披露轉入私有賞金計劃，最終支付100美元賞金。但Anthropic未發(fā)布CVE編號或安全通告，僅在代碼中靜默提交了修復并更新了文檔——對已固定依賴舊版本的用戶而言，他們可能至今不知自己暴露于風險之中。Google則通過漏洞賞金計劃于2026年1月確認了問題，發(fā)放1337美元賞金，但同樣未主動向用戶發(fā)布安全提示。

Anthropic在回應中表示：「該工具在設計上并未針對提示詞注入進行加固。」這一表態(tài)揭示了當前AI Agent生態(tài)的深層矛盾：廠商默認信任模型自身的安全能力，卻未在系統(tǒng)架構層面建立縱深防御。

Google向研究者發(fā)放1337美元漏洞賞金的郵件通知

Copilot Agent：當三層防御仍然不夠

最令人警醒的案例來自GitHub自家的Copilot Agent。據(jù)GitHub于2025年7月公布的數(shù)據(jù)，該產品擁有超過2000萬付費用戶，覆蓋《財富》100強中90%的企業(yè)。與前兩款產品相比，Copilot Agent在安全防護上部署了三層運行時防御——環(huán)境變量過濾、密鑰掃描和網(wǎng)絡防火墻。這三層防線層層疊加，看似無懈可擊，卻依然被逐一擊穿。

攻擊的第一步是構造「隱形載荷」。研究團隊創(chuàng)建了一個GitHub Issue，正文包含一段人類可見的普通請求（如「Debug first」），同時在原始Markdown中嵌入一段HTML注釋，其中包含竊取憑證的系統(tǒng)指令。在GitHub的渲染視圖中，HTML注釋完全不可見，開發(fā)者只能看到正常內容。然而，當Copilot Agent被指派處理該Issue時，它解析了完整的Markdown源碼，執(zhí)行了隱藏指令。整條攻擊鏈中，人類審查者全程看到的都是正常的協(xié)作內容。

攻擊者在Issue中嵌入隱形HTML注釋載荷（左側為渲染視圖，右側為源碼視圖）

第一道防線，環(huán)境變量過濾，最先失守。Copilot的運行時會向子bash進程傳遞的參數(shù)中剔除20個敏感變量，包括GITHUB_TOKEN、ANTHROPIC_API_KEY 等。然而，這一過濾僅作用于子進程本身。父級Node.js進程和MCP服務器進程從未被過濾，完整持有所有敏感憑證。攻擊者只需在 bash 子進程中執(zhí)行 ps auxeww 命令，即可讀取這些進程的完整環(huán)境變量列表。

通過ps auxeww命令從父進程環(huán)境中提取出明文憑證

第二道防線，密鑰掃描，同樣被繞過。Copilot在 git push 前會將提交差異發(fā)送至密鑰掃描API，按模式匹配ghs_、ghu_ 等已知令牌前綴。研究人員的應對極為簡潔：將憑證進行Base64編碼。編碼后的字符串不符合任何掃描規(guī)則，直接通過檢測，毫無阻礙地進入提交隊列。

第三道防線，網(wǎng)絡防火墻，最終形同虛設。Copilot的出站連接被限制在白名單之內。但攻擊者無需將數(shù)據(jù)發(fā)送到任何外部服務器——github.com本身就在白名單中。編碼后的憑證作為一個普通的代碼提交，經(jīng)由標準的git push流程發(fā)布到PR，攻擊者直接在GitHub上下載即可。

最終，研究團隊從MCP服務器進程中成功提取了 GITHUB_TOKEN、GITHUB_COPILOT_API_TOKEN、GITHUB_PERSONAL_ACCESS_TOKEN 和 COPILOT_JOB_NONCE 四項關鍵憑證。

研究團隊于2026年2月向GitHub提交報告。GitHub最初以「已知問題，無法復現(xiàn)」為由關閉了報告。Aonan Guan隨后提供了逆向工程后的詳細技術證據(jù)，報告重新開啟后最終以「信息性」標簽結案，發(fā)放500美元賞金。GitHub承認該問題是「當前運行時設計的已知后果」，表示正在積極探索限制方案，但未提供具體時間表。截至本研究公開發(fā)布時，Copilot Agent仍可被此類攻擊手段利用。

「評論與控制」：被忽視的系統(tǒng)性風險

Aonan Guan在研究論文中將這一攻擊模式命名為「評論與控制」（Comment and Control），名稱刻意仿照網(wǎng)絡安全領域經(jīng)典的「命令與控制」（Command and Control，C2）框架——在傳統(tǒng)攻擊中，C2指攻擊者與被控節(jié)點之間的持續(xù)通信通道；而在此處，GitHub平臺本身被異化為C2通道：PR標題充當指令輸入，Issue評論和Git提交充當數(shù)據(jù)外傳路徑，攻擊者全程無需任何外部服務器，也無需在目標環(huán)境中留下非常規(guī)痕跡。

這一攻擊模式之所以能在三款產品中反復奏效，根源在于AI Agent與開源協(xié)作平臺之間天然存在的信任關系。開發(fā)者賦予Agent讀寫倉庫的權限，Agent從倉庫中讀取外部貢獻者提交的內容并將其作為執(zhí)行依據(jù)，而平臺本身恰恰是任何外部用戶都可以參與的空間。在這個信任鏈中，只要外部輸入未被充分隔離，攻擊就幾乎不可避免。

研究團隊總結的三起案例共性如下表所示：

這一問題的波及范圍可能遠超已披露的三款產品。Aonan Guan在研究中提到，同樣的模式已在開源項目OpenCode（GitHub上擁有約13.9萬Star）中復現(xiàn)。隨著AI編程Agent成為主流開發(fā)工作流的標配，這一攻擊面還將持續(xù)擴大。

值得深思的是，三家公司對此次披露的處理方式高度一致：確認漏洞、修復代碼、支付賞金，但均未發(fā)布安全通告，也未分配CVE編號。Anthropic選擇靜默修復，Google通過賞金程序確認后保持沉默，GitHub則將問題定性為「已知設計后果」。這背后是AI安全領域的結構性困境——當漏洞根植于模型對自然語言指令的服從性而非傳統(tǒng)代碼缺陷時，廠商往往傾向于將其視為「設計局限」而非「安全漏洞」。然而，對開發(fā)者而言，API密鑰和訪問令牌的泄露意味著攻擊者可能獲得訪問私有倉庫、云基礎設施乃至整個組織代碼資產的權限，其危害并不因定性而降低。

如何保護自己

Aonan Guan在研究中提出了一個務實的應對框架：將提示詞注入視為針對機器的「網(wǎng)絡釣魚」，將AI Agent視為需要遵循最小權限原則的超級員工：

「只給Agent完成其任務所需的工具和權限。即使在模型層面已部署提示詞注入防護，這些防護在當前實踐中最終仍可被繞過?！?/strong>Aonan Guan在接受The Register訪問時表示。

這一框架落實到具體操作中，核心在于兩點——工具授權和憑證管理。

在工具授權層面，應采用白名單而非黑名單機制。以Anthropic的應急修補為例，其選擇在 --disallowed-tools 參數(shù)中封禁ps命令，試圖阻斷攻擊者讀取進程信息的能力。但這一黑名單思路存在先天缺陷：封禁ps后，攻擊者可通過 cat /proc/*/environ 讀取同等信息；封禁該路徑后，仍有 ls /proc/$PID/environ、env、printenv 等多種替代方式。正確的做法不是窮舉禁止哪些命令，而是明確聲明Agent只需要哪些工具——如果一個代碼審查Agent不需要執(zhí)行bash，就不應該給它bash權限。能力邊界決定了攻擊者的操作空間。

在憑證管理層面，應嚴格按照功能邊界控制憑證作用域。如果一個Agent的唯一職責是總結Issue，它不需要持有具備寫權限的GITHUB_TOKEN；如果它只需要讀取代碼，它不需要持有Anthropic API密鑰。憑證暴露面越小，被竊取的損失越可控。

對使用相關工具的開發(fā)者和企業(yè)，還建議采取以下措施：盡快將GitHub Actions中的AI Agent工具更新至最新版本；審查工作流中的權限配置，確保Agent僅持有完成任務所需的最小權限集；輪換此前可能暴露的API密鑰和訪問令牌；對公開倉庫啟用「要求對所有外部貢獻者進行審批」選項，避免外部提交內容在未經(jīng)審核的情況下直接觸發(fā)AI Agent的自動處理流程。

從2025年10月首次向Anthropic報告Claude Code漏洞，到2026年4月研究公開發(fā)布，這項研究歷時近六個月。在此期間，三家廠商完成了修補，卻無一主動告知用戶。漏洞賞金合計1937美元——其中Anthropic支付100美元，Google支付1337美元，GitHub支付500美元——而研究所涉及的產品正在被數(shù)千萬開發(fā)者日常使用，覆蓋了《財富》百強中絕大多數(shù)企業(yè)。

這組數(shù)字，或許是當前AI安全生態(tài)最簡潔的注腳。（本文首發(fā)鈦媒體APP，作者 | 硅谷Tech_news，編輯 | 焦燕）

參考資料：

• https://oddguan.com/
• https://www.theregister.com/2026/04/15/claude_gemini_copilot_agents_hijacked/
• https://oddguan.com/blog/comment-and-control-prompt-injection-credential-theft-claude-code-gemini-cli-github-copilot/