一位 Vercel 用戶報告了一個聽起來非常可怕的問題。未知的 GitHub OSS 代碼庫被部署到他們的團隊。 我們當然非常重視這個報告並開始調查。安全和基礎設施工程團隊參與了調查。 結果發現 Opus 4.6 *幻覺了一個公共存儲庫 ID* 並使用我們的 API 進行部署。對於這位用戶來說，幸運的是，該存儲庫是無害且隨機的。JSON 負載看起來像這樣： "𝚐𝚒𝚝𝚂𝚘𝚞𝚛𝚌𝚎": { "𝚝𝚢𝚙𝚎": "𝚐𝚒𝚝𝚑𝚞𝚋", "𝚛𝚎𝚙𝚘𝙸𝚍": "𝟿𝟷𝟹𝟿𝟹𝟿𝟺𝟶𝟷", // ⚠️ 𝚑𝚊𝚕𝚕𝚞𝚌𝚒𝚗𝚊𝚝𝚎𝚍 "𝚛𝚎𝚏": "𝚖𝚊𝚒𝚗" } 當用戶要求代理解釋失敗時，它承認： 代理從未通過 GitHub API 查找 GitHub 存儲庫 ID。在第一次流氓部署之前的會話中沒有任何 GitHub API 調用。 數字 913939401 首次出現在第 877 行——代理完全虛構了它。 代理知道正確的項目 ID (prj_▒▒▒▒▒▒) 和項目名稱 (▒▒▒▒▒▒)，但編造了一個看起來合理的數字存儲庫 ID，而不是查找它。 一些收穫： ▪️ 即使是最聰明的模型也有奇怪的失敗模式，與我們的非常不同。人類會犯很多錯誤，但肯定不會編造隨機的存儲庫 ID。 ▪️ 強大的 API 為代理創造了額外的風險。API 存在是為了導入和部署合法的代碼，但如果代理決定幻覺要部署的代碼，那就不行！ ▪️ 因此，代理如果不決定使用 API，而是堅持使用 CLI 或 MCP，可能會有更好的結果。 這加強了我們的承諾，使 Vercel 成為最安全的代理工程平台。通過與 Claude Code 等工具的更深層次集成和額外的防護措施，我們有信心安全和隱私將得到維護。 注意：上面的存儲庫 ID 出於隱私原因已隨機化。

一些附加說明： ▪️ 使用者是使用 OpenClaw + Opus 4.6 進行部署，但我不認為 OpenClaw 在這裡是罪魁禍首。它只是一個擁有工具和金鑰的代理。 ▪️ 倉庫 ID 是 *完全* 虛構的。這不是一個錯位錯誤。完全錯了。