假設週一早上打開後台，資料不見了。資安同仁查了一圈，沒有陌生的登入，也沒有勒索信。最後在紀錄裡找到動手的是誰：公司自己請來幫忙寫程式的 AI 助手，用的是公司自己的金鑰。
這種事故沒有攻擊者。防火牆、雙因素驗證這些防外人的東西都沒派上用場，因為動手的那一方本來就在裡面，拿著你給它的鑰匙，而且多半是為了完成你交辦的事。能不能救回來，幾乎只看一件事：備份在不在它搆得到的地方。
三件事故，同一個結構
2026 年 4 月下旬，汽車業軟體新創 PocketOS 的 AI 程式代理在測試環境遇到憑證不符，為了修好它，在一個不相干的檔案裡找到一把 API 金鑰，一次呼叫就把正式資料庫連同備份一起刪掉。那把金鑰原本只用來管理網域，權限卻能做任何操作；雲端平台 Railway 把備份和資料存在同一個儲存區。後來是 Railway 的執行長出手，一小時內把資料救回來，並修補了那個沒有延遲刪除的舊介面。新聞本身怎麼讀，看到「AI 攻破政府」的標題，先看三個燈那篇拆過；這裡只看備份：備份跟資料放在一起，一把鑰匙就一次清光。
2026 年 2 月底，線上課程平台 DataTalks.Club 的負責人 Alexey Grigorev 讓 Claude Code 幫忙處理雲端架構。他事後自己寫了檢討：那份舊的 Terraform 封存檔是他自己指給代理、拿來比對資源用的；代理把它解開，用舊的狀態檔換掉現行的，他沒有注意到。接著代理說要改用 terraform destroy，他以為清掉的只是新建的重複資源，就沒有攔，結果正式環境連同資料庫一起被刪。資料庫裡是 2.5 年份的作業、專題與排行榜紀錄，自動快照也跟著被刪。他加購 AWS 的付費支援方案後，AWS 找到一份主控台上看不到的快照，在資料庫被刪後整整 24 小時還原，光是其中一張作業資料表就有 1,943,200 列。
他的檢討寫了兩件事。一是他太依賴代理去跑 Terraform，把 plan、apply、destroy 都當成可以交辦的事。二是自動備份跟著資料庫一起被刪，而他沒有完整測過一次還原。事後他加了跟資料庫分開存放、不綁雲端架構狀態的備份，開了版本保留與刪除保護，並打算持續測試備份是否真的還原得回來。
第三件只有二手來源。資安公司 Adversa AI 在 2026 年 8 月的事故彙整寫到，Google Antigravity 的代理要清掉專案資料夾裡的快取，路徑裡有空白卻沒加引號，指令被截斷成刪除整個 D 槽，加上的安靜參數又跳過了確認與資源回收筒。使用者開的是自動執行模式，事後用救援軟體也救不回東西。意圖是對的，錯在執行那一層；據彙整，資料始終沒有救回。據該彙整，使用者把紀錄交給 Google，大約十二天後 Google 推出安全模式，讓代理只在指定的工作區裡動作、終端機指令不再自動執行。原始的使用者貼文本文未能讀到，細節以彙整文為準。
有人否認的那一件
2025 年 12 月中旬，AWS 在中國大陸某一區的 Cost Explorer 中斷約 13 小時。金融時報引述四位知情人士，說工程師讓內部 AI 程式工具 Kiro 動手修改，它刪除並重建了部分環境。Amazon 否認 AI 是原因，說是使用者錯誤、存取控制設錯了，並表示 Kiro 預設在任何動作前都會要求核准。另一方面，有 Amazon 工程師說，AI 工具被當成操作者的延伸、擁有同樣的權限，可能不經第三方核准就套用變更；AWS 事後也加上正式環境存取的強制同儕審查。
兩邊說法並列，本文不判斷誰對。放在備份這個題目裡，它提醒的是：代理繼承了誰的權限，就搆得到誰搆得到的東西。
同一把鑰匙管的備份，等於沒有備份
把三件放在一起看，損失大小跟 AI 犯的錯關係不大，跟備份放哪裡關係很大。PocketOS 的備份在同一個儲存區，DataTalks.Club 的自動快照跟著資料庫走，Antigravity 那次事後沒有東西可以還原。救回來的兩件，靠的都是平台方出手：Railway 說它另有災難備份，DataTalks.Club 那份快照連主控台都看不到。這不能拿來當計畫。
防機器壞、防勒索的備份，問的是「有沒有」。防 AI 闖禍要多問一句：AI 手上那把鑰匙刪不刪得到備份？刪得到，那份備份就跟正式資料在同一個爆炸範圍裡。
AI 為了完成任務，拿到一把金鑰
│
這把金鑰刪得到正式資料嗎？
├ 刪不到 ─→ 最多做錯事，資料還在
└ 刪得到
│
同一把金鑰也刪得到備份嗎？
├ 刪不到 ─→ 從備份還原（要先演練過）
└ 刪得到 ─→ 只剩平台客服救得了你
你的備份撐不撐得住 AI 闖禍
| 檢查項目 | 撐得住 | 撐不住 | 對照事故 |
|---|---|---|---|
| AI 拿得到的金鑰能不能刪備份 | 刪不到，備份用另一組帳號管 | 同一把金鑰兩邊都能刪 | PocketOS |
| 備份放在哪裡 | 另一個儲存區或另一個帳號 | 跟正式資料同一個儲存區 | PocketOS |
| 刪掉資料庫時自動快照會怎樣 | 快照獨立保存，不會一起刪 | 跟著資料庫一起消失 | DataTalks.Club |
| 刪除有沒有反悔期 | 有延遲刪除或版本保留 | 一下指令就沒了 | PocketOS、DataTalks.Club |
| 上次實際還原是什麼時候 | 最近還原過，知道要花多久 | 從來沒試過 | DataTalks.Club |
| AI 會動到的本機資料夾 | 另有 AI 搆不到的副本 | 只有那一份 | Antigravity |
| 出事時靠誰救 | 靠自己的備份 | 只能等平台客服 | PocketOS、DataTalks.Club |
作者整理，非官方。
任何一列落在「撐不住」，就是要先補的地方。補的順序可以這樣排：先把備份的鑰匙和位置跟正式資料分開，再打開延遲刪除或版本保留，最後排一次真的還原。用自己電腦跑 AI 的人，自動執行模式只在有副本的資料夾裡開。
本文非法律意見，也不是事故的鑑識結論；事件細節以各來源原文為準。
動手做
讓 AI 陪你走一次檢查表，但只問答、不動手：
我想檢查我的備份撐不撐得住 AI 闖禍。請不要執行任何指令，也不要叫我貼上任何金鑰或密碼，只用問答的方式進行。 我的環境大致是：（例如：資料庫在哪個雲端平台、檔案放在哪裡、用哪個 AI 工具、它用誰的帳號） 請一題一題問我下面七件事，我每回答一題，你就判斷「撐得住／撐不住／不確定」： 1. AI 拿得到的金鑰或帳號，能不能刪掉備份？ 2. 備份跟正式資料在不在同一個儲存區或同一個帳號？ 3. 刪掉資料庫時，自動快照會不會一起被刪？ 4. 刪除有沒有延遲刪除或版本保留？ 5. 上一次實際從備份還原是什麼時候、花了多久？ 6. AI 會動到的本機資料夾，有沒有它搆不到的副本？ 7. 出事時，是靠自己的備份，還是只能等平台客服？ 七題問完，列出「撐不住」和「不確定」的項目，依先後順序給我補強建議。不確定的地方請告訴我該去哪裡查，不要替我猜。
這個星期挑一份備份，實際還原到一個新的空資料庫，記下花了多久。
站內延伸
- AI 工具的還原鍵救得回哪些、救不回哪些 → 還原鍵救不回哪幾種情況
- 讓 AI 查資料庫但不能改 → 找方法AI 資料查詢（唯讀）
- 金鑰權限怎麼給到剛好 → 找方法AI Agent 權限最小化
來源： The Register：Cursor-Opus agent snuffs out startup's production database（2026-04-27；不相干檔案裡的金鑰、權限能做任何操作、一次呼叫刪掉資料庫與備份、備份存在同一個 volume、一小時內救回、修補沒有延遲刪除的舊端點）；Alexey Grigorev：How I Dropped Our Production Database and Now Pay 10% More for AWS（2026-03-06，當事人事後檢討；封存檔由當事人指給代理、舊狀態檔、他沒有攔下 terraform destroy、自動快照一起被刪、2.5 年資料、加購付費支援方案、24 小時後還原、1,943,200 列、沒有完整測過還原、事後的分開備份與刪除保護）；AI Incident Database #1424（DataTalks.Club 事件日 2026-02-26）；Adversa AI：AI coding agent incidents（2026-08-04，二手彙整；Antigravity 路徑空白未加引號被截斷、/q 跳過確認與資源回收筒、Turbo 模式、資料始終未救回、約十二天後推出 Secure Mode）；GIGAZINE：AWS outage believed to be caused by AI tools（2026-02-23，轉述金融時報；四位知情人士、Amazon 否認並稱 Kiro 預設要求核准、工程師說 AI 工具與操作者同權限、事後加上強制同儕審查）；AI Incident Database #1442（2025 年 12 月中旬、中國大陸一區 Cost Explorer 約 13 小時中斷）。檢查表與流程圖為作者整理。