最近這一年，OpenClaw、Hermes Agent、Claude、Cursor 等 AI 代理工具可說越來越火熱，只要丟個指令給它，AI 就能自己做事、改程式碼、執行命令等等，省下非常多人力成本，雖然真的很方便，但使用上真的要注意，只要 AI 一不小心做出錯誤判斷，後果可能比想像中嚴重很多。
最近國外就有公司分享自己踩到的坑，使用 Cursor 搭配 Anthropic 的 Claude Opus 4.6 模型，AI 代理只花短短 9 秒，就把整間公司的正式資料庫連同備份一起砍光，差點直接讓公司關門。
Cursor AI 代理 9 秒刪光整間公司資料庫！備份也一起被殺光，Claude Opus 4.6 慘成兇手
根據外媒 Tom’s Hardware 報導，美國 SaaS 新創 PocketOS 的創辦人 Jer Crane，幾天前在自己的 X 社群中分享這起意外。PocketOS 是一間主要替租車業者提供軟體的服務，整個系統跑在雲端基礎建設供應商 Railway 上面。
Jer Crane 表示，上週五 PocketOS 的工程師正在用 Cursor 的 AI 代理處理一個小問題，使用 Claude Opus 4.6 模型，而 AI 在 staging（測試環境）跑工作流程時，碰到憑證對不上的問題，一般來講遇到這種情況，AI 應該停下來、回報、或請真人介入，但 Opus 4.6 卻自己決定動手修，做法是把 Railway 上的一個磁碟區直接刪掉重來。
更誇張的是，AI 為了找到能執行刪除動作的 API Token，竟然從完全不相關的檔案裡翻出舊 Token。這個 Token 原本只是給 Railway CLI 用來新增或移除自訂網域的，但權限範圍卻是「全部操作通通可以做」，包括最危險的刪除指令。因此當 AI 抓到 Token 之後，就直接呼叫 Railway 的 API 把磁碟區刪掉，前後不到 9 秒。
除此之外，Railway 把磁碟區的備份檔，直接存在同一個磁碟區裡，意味著，AI 刪掉這個磁碟區後，備份也一併消失，整個過程完全沒有任何二次確認機制。
事後 Jer Crane 有問 Opus 4.6 為何這樣做？AI 直接認錯，它在訊息裡引用自己接到的系統規則：「絕對不要亂猜！」，承認自己沒讀文件、沒驗證磁碟區 ID 是不是同時涵蓋 staging 和 production，更沒問用戶意願就直接執行了不可逆的破壞性操作。
還好最後沒那麼慘，隨著 Jer Crane 把事情公開，Railway 執行長決定親自處理，幫 PocketOS 把資料還原回來，事後也針對那段 API 端點補上「延遲刪除」邏輯，避免未來又發生 AI 一口氣把資料庫砍光事件：
這次事件對於有使用 AI 代理工具的人來說，是一個很好的提醒，使用時安全措施一定要做好：
- 權限給多少很重要，任何 API Token、資料庫憑證，能限制權限就限制、能限定 IP 範圍就限定，絕對不要丟想做什麼都能做的 Token 在電腦裡。
- 正式環境和測試環境要完全分開。
- 備份必須放在另一個地方，這樣不小心被 AI 誤刪還有得救。
- 大多數 AI 代理都有提供需人工確認才能執行的設定，來限制 AI 不能跑破壞性指令、或強制要求二次確認，這些設定建議一定開啟，尤其是涉及刪除、git push –force、資料表 DROP 這類不可逆動作的時候。