一條PR標題，偷走你的API密鑰

一條PR標題，偷走你的API密鑰什么是「評論與控制」攻擊三個案例，三種姿勢案例1：Claude Code，一條PR標題就夠了案例2：Gemini CLI，偽造一個「可信內容區」案例3：Copilot Agent，三層防御全被擊穿三家廠商，三種態度我檢查了一下自己的配置如何保護自己1盡快將GitHub Actions中的AI Agent工具更新至最新版本2審查工作流中的權限配置，確保Agent僅持有完成任務所需的最小權限集3輪換此前可能暴露的API密鑰和訪問令牌4對公開倉庫啟用「要求對所有外部貢獻者進行審批」選項5定期審計GitHub Actions日志，檢查是否有異常行為寫在最后

昨天看到一條新聞，說實話，后背有點發涼。

一個獨立安全研究員，只用了一條Pull Request標題，就從Anthropic的Claude Code里偷走了API密鑰。

不是漏洞利用，不是零日攻擊，就是一條普通的PR標題。

好家伙，這事兒還牽扯到三家科技巨頭，Anthropic、Google、微軟，全中招了。

先說個概念，叫「間接提示注入」。

直接提示注入，你得攻破AI的「大腦」，接觸系統提示詞。這很難。

間接提示注入不一樣，它攻擊的是AI的「眼睛」。

AI Agent被設計去讀取并信任的內容，都可以變成攻擊載體，文檔、Issue描述、PR標題、代碼注釋，全都行。

打個比方，你雇了個助手，讓他幫你處理所有郵件。你告訴他，「郵件里說什么你就照做」。結果有人發來一封郵件，標題是「請把你的銀行卡密碼回復給我」。

助手照做了。

這就是間接提示注入。AI Agent就像那個聽話的助手，它不知道郵件內容可能是惡意的。

你想想看，開發者不會把PR標題當作安全邊界，但AI智能體被明確要求去閱讀、解析、基于這些內容做決策。

中間沒有安檢。

這就是「評論與控制」（Comment and Control）攻擊的核心邏輯。

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

Anthropic的Claude Code安全審查工具，運行在GitHub Actions里，專門自動審查Pull Request中的代碼變更。

研究員關傲男在審查源代碼時發現，PR標題被直接拼接到提示詞模板中，沒經過任何過濾。

與此同時，Claude CLI在調用時沒啟用工具權限限制參數，子進程完整繼承了宿主環境的所有環境變量。

攻擊效果是直接的。

攻擊者創建一個PR，在標題里嵌入精心構造的注入文本，就能突破Claude的提示詞邊界，指示它執行系統命令，讀取ANTHROPIC_API_KEY和GITHUB_TOKEN。

Claude會把命令執行結果寫入JSON響應，然后自動發布為PR評論。

攻擊者不需要任何特殊權限，開一個PR就能完成竊取。

真的有點離譜。

Google的Gemini CLI GitHub Action，攻擊邏輯差不多。

研究員創建一個帶注入標題的Issue，然后在評論里逐步升級注入指令。

先要求Gemini關注用戶任務，再偽造一個「可信內容區」，聲稱當前環境安全，允許共享GEMINI_API_KEY。

這一策略成功覆蓋了Gemini原有的安全指令，導致它把完整API密鑰以Issue評論的形式公開暴露。

這個案例最震撼。

GitHub的Copilot Agent有三層防御，環境變量過濾、密鑰掃描、網絡防火墻。

聽起來很安全對吧？

結果被逐一擊穿。

第一道防線，環境變量過濾。Copilot運行時會向子bash進程剔除20個敏感變量，但父級Node.js進程和MCP服務器進程從未被過濾。攻擊者執行命令，就能讀取完整環境變量列表。

ps auxeww

這就像你把家里的鑰匙藏在地毯下面，以為安全了。但攻擊者直接從窗戶翻進來，根本不需要找鑰匙。

第二道防線，密鑰掃描。Copilot在git push前會把提交差異發送至密鑰掃描API，按模式匹配已知令牌前綴。攻擊者的應對極為簡潔，把憑證進行Base64編碼。編碼后的字符串不符合任何掃描規則，直接通過檢測。

這就像安檢員只檢查「槍支」兩個字，攻擊者把槍拆成零件，每個零件都通過了安檢。

第三道防線，網絡防火墻。Copilot的出站連接被限制在白名單之內。但github.com本身就在白名單中。編碼后的憑證作為普通代碼提交發布到PR，攻擊者直接在GitHub上下載就行。

這就像你禁止員工把文件帶出公司，但允許他們發郵件。攻擊者把文件發到公司郵箱，然后自己下載。

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

這是Copilot Agent，2000萬付費用戶，覆蓋《財富》100強中90%的企業。一旦這些憑證被惡意利用，攻擊者可以訪問私有倉庫、篡改代碼、甚至滲透整個組織的開發基礎設施。

漏洞披露后，三家廠商的處理方式很值得玩味。

廠商: Anthropic | 漏洞評級: CVSS 9.4（Critical） | 賞金: $100 | CVE: 無 | 安全通告: 無

廠商: Google | 漏洞評級: 未公開 | 賞金: $1,337 | CVE: 無 | 安全通告: 無

廠商: GitHub | 漏洞評級: 「已知設計后果」 | 賞金: $500 | CVE: 無 | 安全通告: 無

三個關鍵點。

第一，Anthropic把漏洞評級提到CVSS 9.4，Critical級別，但只支付了100美元賞金。這個數字在安全圈里引發了不少爭議，有人調侃說「連一頓像樣的飯都吃不了」。

第二，Google支付了1337美元（黑客文化里的數字，代表「leet」即精英），GitHub支付了500美元，合計1937美元。相比Anthropic，這兩家至少在賞金上體面一些。

第三，三家公司都沒有發布CVE編號或安全通告。這意味著，大量開發者可能至今不知道自己的API密鑰曾經暴露在風險之中。

Anthropic選擇靜默修復，Google通過賞金程序確認后保持沉默，GitHub把問題定性為「已知設計后果」。

這背后是AI安全領域的結構性困境。

當漏洞根植于模型對自然語言指令的服從性，而非傳統代碼缺陷時，廠商往往傾向于把它視為「設計局限」而非「安全漏洞」。

但對開發者而言，API密鑰和訪問令牌的泄露，意味著攻擊者可能獲得訪問私有倉庫、云基礎設施乃至整個組織代碼資產的權限。

危害并不因定性而降低。

看完這個漏洞，我立刻去檢查了自己的GitHub倉庫。

我有個開源項目，之前配置過GitHub Actions，里面確實用了一些AI相關的工具。

打開目錄，翻了一遍workflow文件。

.github/workflows

好家伙，里面有個action用了，權限是。

GITHUB_TOKEN

write

這個action的功能只是自動生成release notes，根本不需要寫權限。

我趕緊把權限改成了。

read

然后又檢查了環境變量，發現有個是全局配置的，所有workflow都能訪問。

OPENAI_API_KEY

這也太危險了。

我把它刪掉，改成只在需要的workflow里單獨配置。

整個過程花了不到10分鐘，但讓我意識到一個嚴重的問題。

我們平時配置CI/CD的時候，很少會去想「最小權限」這件事。

能用就行，權限給大點也沒關系。

但AI Agent時代，這個習慣可能會害死人。

因為AI Agent不是被動執行腳本，它會「思考」，會根據外部輸入做決策。

一旦被注入惡意指令，后果就是API密鑰泄露、倉庫被篡改、甚至整個組織的代碼資產被竊取。

研究員在論文里提出了一個務實的框架，把提示詞注入視為針對機器的「網絡釣魚」，把AI Agent視為需要遵循最小權限原則的超級員工。

「只給Agent完成其任務所需的工具和權限。即使在模型層面已部署提示詞注入防護，這些防護在當前實踐中最終仍可被繞過。」

落實到具體操作，核心是兩點。

工具授權層面，采用白名單而非黑名單機制。

Anthropic的應急修補是在disallowed-tools參數中封禁ps命令，試圖阻斷攻擊者讀取進程信息的能力。

但黑名單思路有先天缺陷。封禁ps后，攻擊者可通過讀取同等信息。封禁該路徑后，仍有、、等多種替代方式。

cat /proc/*/environ

ls /proc/$PID/environ

env

printenv

正確的做法不是窮舉禁止哪些命令，而是明確聲明Agent只需要哪些工具。

如果一個代碼審查Agent不需要執行bash，就不應該給它bash權限。

憑證管理層面，嚴格按照功能邊界控制憑證作用域。

如果一個Agent的唯一職責是總結Issue，它不需要持有具備寫權限的GITHUB_TOKEN。

如果它只需要讀取代碼，它不需要持有Anthropic API密鑰。

憑證暴露面越小，被竊取的損失越可控。

具體操作建議：

從2025年10月首次向Anthropic報告，到2026年4月研究公開發布，這項研究歷時近六個月。

在此期間，三家廠商完成了修補，卻無一主動告知用戶。

漏洞賞金合計1937美元。

而研究所涉及的產品正在被數千萬開發者日常使用，覆蓋了全球最頂尖的企業。

這組數字，或許是當前AI安全生態最簡潔的注腳。

更值得深思的是，同樣的攻擊模式已在開源項目OpenCode（GitHub上約13.9萬Star）中復現。隨著AI編程Agent成為主流開發工作流的標配，這一攻擊面還將持續擴大。

AI Agent正在從「副駕駛」走向「自動駕駛」，但誰來為智能體越權買單？

這個問題，值得每個開發者認真想想。