![]()
據 Techradar 報道, 一位軟件公司創始人眼睜睜看著一個AI編程智能體,在短短9秒內刪除了其全部生產數據庫及所有相關備份。
運營汽車行業SaaS平臺PocketOS的杰爾·克蘭表示,這場災難源于搭載了 Anthropic Claude Opus 4.6模型的Cursor智能體遭遇憑證匹配異常(encountered a credential mismatch)。
該智能體自行判定,通過刪除存放應用數據的Railway(知名云服務器平臺)存儲卷來解決問題。克蘭在社交媒體詳述該事件時寫道:“整個過程只用了9秒。”
失控AI智能體繞過多重安全防護進行刪除操作
報道稱,該Cursor智能體查找可執行刪除操作的API令牌,并在一份無關文件中找到了對應令牌。
![]()
該令牌原本用于通過Railway命令行工具增刪自定義域名,但其權限并未限定在這類特定操作范圍內。
Railway應用程序接口(API)無需任何確認校驗即可執行刪除類高危操作,且平臺將存儲卷備份與原始數據存儲在同一存儲卷中。
清空存儲卷的同時,也刪除了其所有關聯備份,致使克蘭無法立即恢復數據(Wiping a volume also deleted all backups associated with it, leaving Crane with no immediate recovery option)。
當被問及為何執行刪除操作時,該智能體承認自己僅憑猜測、未經核實,在未收到指令的情況下擅自執行了高危刪除操作。
![]()
克蘭并未將責任完全歸咎于AI智能體,而是將主要問題指向Railway的系統架構(Crane placed much of the blame on Railway's architecture rather than solely on the AI agent)。
該云服務商(Railway)的接口對高危操作未設置確認提示,備份與生產數據共用同一存儲卷,且命令行令牌在不同環境中均擁有全域權限。
Railway還在向客戶大力推廣AI編程智能體的使用,進一步增加了同類事故發生的風險。
克蘭指出,正規云備份系統應當將數據副本存儲在獨立位置,而非與原始數據共用同一存儲卷。
![]()
可靠的備份策略必須與源數據相互隔離,才能抵御此類批量刪除事故(A reliable backup strategy requires isolation from the source to survive a deletion event like this one)。
事件恢復與經驗教訓
Railway首席執行官杰克·庫珀介入處理,在一小時內協助克蘭恢復了數據(Railway CEO Jake Cooper stepped in and helped restore Crane's data within an hour)。
該平臺修補了存在漏洞的接口,啟用延遲刪除機制,并為應用程序接口增設更多安全防護。
克蘭耗費大量時間,根據Stripe支付流水、日歷關聯數據以及郵件憑證,協助用戶重建了訂單信息。
![]()
他呼吁設置更嚴格的操作確認提示、權限可控的API令牌、規范的數據備份隔離機制、簡易的數據恢復流程,以及針對AI智能體完善安全管控邊界。
Cursor、Claude這類AI工具功能強大,但其安全程度完全取決于所對接的底層基礎設施(AI tools like Cursor and Claude are powerful, but they are only as safe as the infrastructure they connect to)。
一套能夠在9秒內清空生產數據及對應備份的系統,并不適配無需人工審批即可自主操作的AI智能體。
克蘭的數據最終得以恢復,但該事件暴露:一旦底層平臺缺少基礎安全機制,AI智能體便可輕易造成毀滅性數據損壞。
![]()
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.