“僅用時9秒”：失控的AI智能體便自主刪除了全部數據庫及備份

據 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智能體便可輕易造成毀滅性數據損壞。