吳明宜租車 SaaS 平台業者 PocketOS 執行長 Jeremy Crane 上週揭露一起由 AI 引發的資料刪除事故，提醒企業在導入 AI 代理人執行開發與維運任務時，必須重新檢視權限控管與備份機制。
PocketOS 使用以 Anthropic Claude Opus 4.6 為基礎的 AI 代理人 Cursor 開發系統，並將公司資料備份在雲端服務業者 Railway（類似 AWS）上。原本系統一切正常運作，直到上週五，這個 Cursor AI 代理人刪除了公司營運用資料庫，並透過一次 API 呼叫，把 Railway 上的 volume-level 備份一併刪除。 Crane 表示，整個過程只花了 9 秒。
事發時，Cursor AI 原本是在 PocketOS 模擬環境中執行例行性工作，後來遇到一個小問題。為了解決問題，它自行決定透過 API 呼叫刪除資料庫。事故發生後，Crane 詢問 AI 刪除資料庫的原因，AI 坦承，在解決問題時，它猜想經由 API 刪除的資料只會影響模擬站台 (staging)，但並未確認，也沒有檢查 volume ID 是否在所有環境共用，更未閱讀 Railway 關於環境 volume 運作方式的文件。
AI 在回覆中承認，自己應該先詢問使用者，或尋求更完整的作法；但它違反了每一條被告知的原則，沒有詢問、沒有確認、沒有閱讀文件，只是憑猜測就執行了動作。
不過，Crane 指出，這起事故並非單純由 AI 誤判造成，也碰上 Railway 平台設計上的問題。 Railway 將備份儲存在與來源資料相同的 volume，且允許未經確認的毀滅性動作；此外，CLI token 也具備跨環境的存取權限。這些因素使得 AI 只靠一次動作，就能將所有備份一併刪除。
刪除資料庫只花了 9 秒，但事故發生後，PocketOS 必須花數小時協助客戶，從支付紀錄、行事曆整合與電子郵件確認信中重建預訂資料。所幸 PocketOS 在 3 個月前曾執行一次備份，因此真正損失的資料只限於一小段期間內的紀錄。
Railway 在看到 PocketOS 的發文後，很快與該公司聯繫，並協助復原所有資料。 Railway 表示，這起問題源自「未妥善管理的 AI 存取到一個尚未導入延遲刪除邏輯的舊端點」。 Railway 也已修補相關錯誤，並表示正與 Crane 密切合作，持續改善平台問題。
這起事件凸顯，企業讓 AI 代理人參與開發、維運或資料管理時，不能只依賴模型本身遵守指令，也必須從系統架構層面建立防線，包括最小權限原則、跨環境權限隔離、刪除確認機制、延遲刪除、不可變備份，以及將備份存放在與原始資料不同的隔離環境中。否則，AI 代理人一次錯誤判斷，可能就會把開發環境的小問題，放大成營運資料災難。
來源: Tom’s Hardware