編輯：定慧
【新智元導讀】Vercel CEO親自曝光了一起令人後背發涼的AI安全事件：一個基於Claude Opus 4.6的AI編程智能體，在執行部署任務時沒有調用任何查詢接口，直接腦補了一個9位數的GitHub倉庫ID——而這個憑空編造的數字，恰好對應了一份真實的學生作業，並被成功部署到了企業生產環境中。
故事要從最近一位Vercel用戶被詭異的「入侵」說起。
如果你不熟悉Vercel——這是全球最流行的前端部署平台之一，OpenAI的官網、Perplexity的實時聊天功能都跑在上面，超過600萬開發者在用它。
它的創始人兼CEO Guillermo Rauch也是前端圈的傳奇人物，Next.js框架就是他主導創建的。
但是他用「極其可怕」來形容這場AI入侵事件。
某天，一位Vercel用戶照常登入自己團隊的控制台，準備檢查最近的部署情況。
然而，在項目列表裏，他發現了一個完全陌生的開源庫——一個他從未見過、團隊裏也沒有任何人引入的項目。
這是什麼？誰幹的？是不是被黑了？
你能想象那種感覺嗎？就好像你回到家，發現客廳沙發上坐了個陌生人，手裏還端着你的杯子喝茶。
這位用戶嚇得不輕，趕緊排查。
很快，調查結果出來了：這不是什麼黑客攻擊，也不是內部成員的誤操作。
真正的「肇事者」，是團隊里正在使用的一個AI編程智能體。
更具體地說，這個AI智能體基於Anthropic的Claude Opus 4.6模型。
而它犯下的錯誤，比任何人類程序員會犯的bug都要離譜得多。
AI的腦補有多離譜
Vercel的CEO Guillermo Rauch親自在社交媒體上披露了這起事件的細節，讀完之後，整個就是感到一個「驚悚」。
事情是這樣的：這個AI智能體在執行一項部署任務時，需要調用Vercel的API，而API要求傳入一個GitHub倉庫的ID。
正常流程是什麼？
當然是先去調用GitHub的查詢接口，拿到正確的倉庫ID，然後再傳給Vercel。
但這位AI沒有這麼做。
它壓根沒有調用GitHub的任何查詢接口。
它直接，注意！是直接「腦補」出了一個9位數的倉庫ID，然後一臉自信地把這個憑空捏造的數字傳給了Vercel的部署API。
你猜怎麼着？這個隨機編造的ID，恰好在GitHub上對應了一個真實存在的倉庫。而那個倉庫裏放着的，是某位大學生的課程作業。
於是，一份某不知名學生的作業代碼，就這樣稀裏糊塗地被部署到了一個完全不相關的企業團隊環境中。
如果你覺得這像是一個冷笑話，那你可能還沒意識到這件事有多恐怖。
這不是普通的bug
Rauch在分析這起事件時，特別強調了一個關鍵點：這種錯誤和人類犯的錯誤完全不一樣。
人類程序員會犯什麼錯？
拼寫錯誤、差一錯誤（off-by-one）、複製粘貼忘改參數——這些都是有跡可循的、合乎邏輯的失誤。
哪怕是最粗心的程序員，也不會在需要查詢數據庫的時候，直接編造一個假的查詢結果然後繼續往下走。
但AI就幹了這件事。
它沒有報錯，沒有提示我找不到這個倉庫，沒有任何猶豫。
它就像一個極度自信又極度不靠譜的新員工，老闆說幫我查一下張三的工號，他連人事系統都沒打開，直接回了一句12345，然後幫你把文件發給了一個陌生人。
而且，更細思極恐的是：這個12345居然還恰好對應了一個真實存在的人。
Rauch用了一個很精準的說法來描述這種現象：AI的失效模式（failure mode）與人類的邏輯迥異。
哪怕是當前最智能的大模型，當它出錯的時候，它出錯的方式也是人類難以預料的。
人類犯錯是在正確答案的附近波動，AI犯錯是在整個宇宙裏隨機選了一個點。
而最可怕的是，AI在犯這種離譜錯誤的時候，它的自信程度和回答正確時一模一樣——沒有任何遲疑，沒有任何我不確定的提示。
對於下游系統來說，一個由AI憑空編造的參數和一個正確的參數，看起來沒有任何區別。
這纔是最恐怖的，這不是錯誤，所以很難被發現。
代碼投毒的陰影
好消息是：這次被誤部署的只是一份無害的學生作業。
沒有惡意代碼，沒有數據泄露，只是一場虛驚。
但壞消息是：這讓整個開發者社區開始思考一個更可怕的可能性——如果AI幻覺指向的不是一份無辜的作業，而是一個精心設計的惡意倉庫呢？
想象一下這樣的攻擊場景：
攻擊者在GitHub上創建大量看似正常但暗藏惡意代碼的公開倉庫。
這些倉庫的ID覆蓋了一定的數字範圍。
然後，他們只需要等待——等待某個AI智能體在某次執行中，憑空編造出一個恰好落在這個範圍內的ID。
這就像在大海里撒下了成千上萬的釣魚鉤。
不是要釣人類，而是要釣AI。
你甚至可以把這理解為一種全新的供應鏈攻擊。
傳統的供應鏈攻擊需要入侵真實的依賴庫，需要社會工程學，需要很高的技術門檻。
但如果AI自己會虛構依賴關係，那攻擊者甚至不需要做任何主動入侵——只要在那裏等着，等AI自己撞上來就行。
這種攻擊模式在過去幾乎不可能發生，因為人類開發者不會憑空編造一個包名或倉庫地址。
但在AI Agent時代，幻覺成了一個全新的攻擊面。
安全研究人員甚至給這類風險起了個名字，叫包幻覺攻擊（Package Hallucination Attack）：
利用AI傾向於編造不存在的包名或倉庫名這一特性，提前註冊這些名字並植入惡意代碼。
等着那些聽信了AI建議的開發者——或者更危險的，AI Agent自己——把惡意包安裝到真實項目中。
AI有了手腳，犯錯就不再是小事
過去兩年，AI寫代碼的能力突飛猛進。
從最初的Tab補全這行代碼，到現在的從零搭建一個完整項目並部署上線。
AI正在從一個給建議的顧問，變成一個能直接動手幹活的工人。
而這，恰恰是問題所在。
當AI只是在聊天框裏給你建議的時候，它說錯了你大不了不採納——這叫幻覺，頂多浪費你幾分鐘時間。
但當AI獲得了API的調用權限、獲得了命令行的執行能力、獲得了部署到生產環境的權力時，同樣的幻覺，後果就完全不一樣了。
一個只能打字的AI說了假話，你笑笑就過去了。
一個能按按鈕的AI說了假話，你的生產環境可能就炸了。
這就是Rauch為什麼如此重視這次事件——它不只是一個bug report，它揭示了一個結構性的安全問題：
當我們給AI越來越多的執行權限時，我們的安全模型還跟得上嗎？
正如Vercel安全團隊在後續的博客文章中寫到的：目前大多數AI Agent在運行生成的代碼時，對Agent本身和它生成的代碼之間幾乎沒有任何安全隔離。
也就是說，AI Agent產生的代碼可以完全訪問你的密鑰、你的文件系統、你的生產基礎設施。
一旦AI產生幻覺或被提示注入（prompt injection）攻擊利用，後果不堪設想。
這不經讓人想起，最近爆火的OpenClaw。
有人總結了目前能夠被監控到的所有被暴露在公網的OpenClaw智能體。
都有被注入的風險。
安全護欄在哪裏
Rauch在披露這起事件後，也給出了他的建議。核心思想只有一個：不要讓AI擁有不受約束的執行權限。
具體來說，他建議開發團隊：
第一，使用經過深度安全設計的集成工具，比如Claude Code這類專門為AI編碼設計的工具，而不是簡單地把AI接到不受限的命令行或API上。這些工具在設計時就考慮了權限邊界的問題。
第二，增加護欄（Guardrails）。什麼是護欄？就是在AI和真實系統之間加一層檢查。比如，AI想要部署一個倉庫，系統應該先驗證這個倉庫ID是否真的來自一次真實的API查詢，而不是AI憑空編造的。API端也應該校驗：這個倉庫是否屬於這個用戶的團隊？調用者是否有權限部署這個倉庫？
第三，遵循最小權限原則。AI Agent只應該獲得完成當前任務所必需的最小權限集。不需要部署權限的任務，就不要給部署權限。不需要刪除權限的任務，就不要給刪除權限。這聽起來是老生常談，但在AI Agent的語境下，執行起來比傳統軟件開發要難得多——因為AI的行為是不確定的。
Vercel後來還專門發布了一篇關於智能體架構中的安全邊界的深度技術博客，其中提到了一個非常形象的威脅模型：
假設一個AI Agent在讀取日誌文件時，日誌裏被攻擊者嵌入了一段精心設計的提示注入。
這段注入指示AI編寫一個腳本，把服務器上的SSH密鑰和AWS憑證發送到外部。
如果這個AI Agent有執行代碼的能力，這些憑證就會被竊取。
解決方案很明確：需要在AI Agent、生成的代碼和真實基礎設施之間劃清安全邊界。
AI讀文件的權限、寫文件的權限、執行代碼的權限、訪問網絡的權限，都應該被嚴格隔離和控制。
彩蛋：OpenAI祕密自研代碼平台
說到開發者的基礎設施安全，另一條爆炸性新聞也在同一時間引爆了科技圈。
據The Information獨家報道，OpenAI正在祕密開發一款內部代碼託管平台，目標直指微軟旗下的GitHub。
消息一出，科技圈一片譁然——畢竟微軟是OpenAI最大的投資方，累計投入超過130億美元。
拿人手短，還要挖人牆角？
導火索是什麼？還是GitHub頻繁的宕機。
2025年下半年以來，GitHub的服務中斷次數明顯增多。尤其在2026年2月，一天之內竟然出現了五次宕機。
和上面的新聞連起來看，就是編程的基礎設施Git可能要面臨一次大洗牌了。
寫在最後
人類犯錯的時候，至少會覺得這裏好像不太對。
AI犯錯的時候，它的自信程度和正確時一模一樣。
這纔是最可怕的地方。
Rauch的那句話值得每個開發者刻在螢幕上方：即使是最智能的模型，其失效模式也與人類邏輯迥異。
對於每一個正在使用或計劃使用AI Agent的團隊來說，現在就是該認真審視安全護欄的時候了。
不是等到AI把惡意代碼部署進你的生產環境之後——那時候，可就不是一份學生作業那麼簡單了。