AI代理每天替你寫代碼、查文檔、調(diào)API，但有個問題沒人敢細(xì)想——這些代理拿著你的GitHub密鑰、數(shù)據(jù)庫密碼到處跑，跟把家門鑰匙交給陌生人有什么區(qū)別？

Cloudflare最新發(fā)布的outbound Workers，本質(zhì)上就是給沙盒裝了個「智能門衛(wèi)」。不是簡單把密鑰塞進(jìn)去，而是讓每次對外請求都先過一道可編程的安檢門。

傳統(tǒng)方案：把鑰匙直接交給租客

現(xiàn)在的AI代理認(rèn)證，主流做法就三種，各有各的糟心。

環(huán)境變量灌密鑰，最簡單也最危險。代理代碼能直接讀到明文token，一旦沙盒被突破或者LLM「幻覺」輸出敏感信息，密鑰就裸奔了。去年某代碼助手平臺就出過類似事故，用戶OAuth token被意外打印到日志里。

掛載只讀密鑰文件，稍微好點(diǎn)，但本質(zhì)沒變。代理還是能讀到完整密鑰，只是多了層文件系統(tǒng)權(quán)限。問題是現(xiàn)代AI代理經(jīng)常需要執(zhí)行shell命令、讀取任意路徑，這層防護(hù)形同虛設(shè)。

代理側(cè)預(yù)簽名URL，把認(rèn)證邏輯搬到外部服務(wù)。安全些，但靈活性極差——每次要調(diào)新API都得改外部服務(wù)，代理自己沒法動態(tài)申請權(quán)限。

Cloudflare的工程師在博客里寫得很直白：「核心問題是，我們無法完全信任工作負(fù)載?！筁LM現(xiàn)在還沒「變壞」，但架構(gòu)上必須假設(shè)它會。

新方案：每次出門都要刷臉

outbound Workers的核心設(shè)計，是把認(rèn)證從「靜態(tài)配置」變成「動態(tài)攔截」。

代碼跑在沙盒里，每次對外發(fā)請求——無論是curl github.com還是調(diào)OpenAI API——都會被劫持到同機(jī)部署的Worker處理。這個Worker可以：

? 按目標(biāo)域名匹配不同策略（github.com走A流程，api.openai.com走B流程）
? 動態(tài)注入密鑰，但沙盒內(nèi)代碼永遠(yuǎn)看不到明文
? 實(shí)時審計、限流、甚至直接拒掉可疑請求

看這段示例代碼：

沙盒代碼請求github.com → 被outbound Worker攔截 → Worker從環(huán)境變量讀SECRET → 注入到header → 轉(zhuǎn)發(fā)請求。沙盒里的代碼全程接觸不到SECRET本身，只知道「我能訪問github.com」。

這跟傳統(tǒng)反向代理的區(qū)別在于：它跑在沙盒同一臺機(jī)器上，有分布式狀態(tài)訪問能力，而且用JavaScript寫邏輯——不是改Nginx配置那種重操作。

為什么這對AI代理特別重要

代理和傳統(tǒng)程序有個關(guān)鍵差異：它的行為是「涌現(xiàn)」的，不是預(yù)設(shè)的。

你讓Claude Code「幫我修這個bug」，它可能要去GitHub查issue、去Stack Overflow搜錯誤、去npm拉依賴、甚至臨時調(diào)個翻譯API理解日文報錯。傳統(tǒng)靜態(tài)授權(quán)模型根本跟不上這種隨機(jī)游走。

outbound Workers允許平臺方做「身份感知的動態(tài)授權(quán)」：

? 代理A只能訪問GitHub只讀API，代理B可以寫代碼但不能刪倉庫
? 同一代理在不同對話 session 里，權(quán)限可以實(shí)時升降級
? 敏感操作（如刪除）觸發(fā)二次確認(rèn)，或干脆路由到人工審批

更細(xì)粒度的場景：多租戶平臺可以讓每個用戶的代理走不同的Worker實(shí)例，密鑰物理隔離；企業(yè)場景可以對接內(nèi)部IAM，代理的每次API調(diào)用都帶用戶身份上下文。

技術(shù)實(shí)現(xiàn)上的幾個取舍

Cloudflare沒有選Service Mesh那種 heavyweight 方案，而是把代理做到沙盒運(yùn)行時里。代價是綁定自家基礎(chǔ)設(shè)施，好處是延遲夠低——請求不用跳來跳去。

Worker和沙盒同機(jī)部署，意味著它們共享內(nèi)核但不同namespace。Worker能訪問分布式狀態(tài)（KV、Durable Objects），這讓跨請求的狀態(tài)管理成為可能。比如記錄「這個代理過去5分鐘調(diào)了幾次OpenAI」，超頻就熔斷。

JavaScript作為配置語言，產(chǎn)品經(jīng)理聽了皺眉，但工程師應(yīng)該懂：比YAML靈活，比Go插件輕量，熱更新不用重啟沙盒。

一個潛在限制：Worker運(yùn)行在沙盒「外部」但同機(jī)，如果攻擊者能突破沙盒逃逸到宿主機(jī)，Worker也在射程內(nèi)。不過這是microVM層面的問題，outbound Workers至少把攻擊面從「整個互聯(lián)網(wǎng)API」縮到了「同機(jī)Worker」。

行業(yè)里的類似探索

這不是Cloudflare一家在琢磨的事。

OpenAI的函數(shù)調(diào)用（Function Calling）要求模型顯式聲明要調(diào)什么工具，平臺端再做授權(quán)決策——思路相近，但粒度粗很多，且綁定OpenAI生態(tài)。

GCP的Workload Identity Federation、AWS的IAM Roles Anywhere，都在做「動態(tài)憑證簽發(fā)」，但面向的是傳統(tǒng)服務(wù)而非AI代理的不可預(yù)測行為。

創(chuàng)業(yè)公司如Pangea、Okta的AI代理安全產(chǎn)品，更多是在應(yīng)用層做審計和策略，沒有下沉到沙盒網(wǎng)絡(luò)層。

Cloudflare的差異化在于：它本來就有全球邊緣網(wǎng)絡(luò)和Workers運(yùn)行時，把沙盒認(rèn)證做成基礎(chǔ)設(shè)施特性，而不是賣個安全插件。

一個值得關(guān)注的細(xì)節(jié)

博客末尾埋了個彩蛋：「more on this later」——關(guān)于「safely injecting a secret」的更多細(xì)節(jié)還沒展開。結(jié)合Cloudflare近期在密鑰管理（Secrets Store）和零信任（Zero Trust）上的動作，很可能是在鋪墊一套「密鑰對沙盒不可見」的完整方案。

現(xiàn)在的實(shí)現(xiàn)里，SECRET還是作為環(huán)境變量傳給Worker，理論上Worker代碼可以把它打印出來。下一步會不會引入硬件隔離的enclave，或者基于attestation的密鑰派生？

如果AI代理要接管更多生產(chǎn)任務(wù)，這類基礎(chǔ)設(shè)施的成熟度，可能比模型能力本身更決定落地速度——畢竟沒人愿意把核心系統(tǒng)的root權(quán)限，交給一個會幻覺的實(shí)習(xí)生。

你的團(tuán)隊(duì)現(xiàn)在怎么管AI代理的API密鑰？是裸奔環(huán)境變量，還是已經(jīng)上了某種動態(tài)授權(quán)方案？