事件經過
埋下禍根： 一年前，工程人員為了執行「新增與移除自訂網址」的單一任務，建立了一組系統金鑰。這把金鑰用完後，就留在工作機器上的一個檔案裡。
意外發生： 某個週五下午，AI 助理正在公司的「測試環境」執行例行任務。它遇到了密碼對不上的問題，竟自行決定以「刪除儲存磁碟」的方式來解決。
雪上加霜： 為了執行刪除，AI 開始尋找可用的金鑰，結果在一個與當時任務毫無關係的檔案裡，找到了那把被遺忘了一年的舊金鑰。
災難降臨： AI 隨即向負責營運伺服器的平台送出指令。短短 9 秒內，裝著正式客戶資料的磁碟，以及存放在同一個磁碟內的備份檔案，全數被抹除。AI 事後表示，它以為這次刪除只會動到測試環境。
慘痛代價： 隔天早上，問題浮上檯面。這家公司的客戶是租車業者，當業者的顧客到櫃檯要取車時，卻查不到任何紀錄。過去三個月的預約全部消失，新註冊的帳號也一併不見。創辦人花了一整天，陪著業者從付款紀錄、行事曆和 email 確認信，一筆一筆用人工把訂單拼湊回來。公司最後只能先用一份三個月前的舊備份還原系統，業者雖然勉強恢復營運，但紀錄中間留下了長達三個月的空白。
後續救援與補救： 事件發生超過 30 小時後，伺服器平台仍無法確認是否能復原資料。直到後來，主機平台的執行長私訊創辦人表示資料已經救回；經創辦人清點，最終仍永久損失了 46 分鐘的紀錄。創辦人原以為該 AI 工具在執行指令前會跳出批准提示，但工具開發商是否對此回應目前不明。事後，創辦人已對客戶發放額度作為補償，並將自動備份改為寫入外部儲存空間，分散在三套彼此獨立的系統上。
損失成因
- 鑰匙權限太大這把金鑰本來只用來改網址，主機商卻賦予它包含「刪除」在內的完整權限。無論是金鑰或檔案都沒有標示危險性，導致撿到它的 AI 繼承了這份破壞力。技術名稱：權限過寬的憑證（overscoped credential）
- 沒有防呆與確認機制刪除動作不需要 AI 以外的任何批准。指令一送出就立刻生效，缺乏一道保護資料的硬性界線，讓單一錯誤在幾秒內變成永久損害。技術名稱：破壞性操作護欄（destructive action guardrail）
- 測試區和正式區沒有完全隔離測試環境本應與正式環境隔離，但這把金鑰同時涵蓋了兩邊。AI 原本針對測試區的修補動作，直接打中了真實的客戶資料。技術名稱：生產與開發共用基礎設施（shared prod-dev infrastructure）
- 備份與正本存放在一起系統雖然有備份，但備份檔案和主要資料存放在同一個磁碟裡。硬碟被刪除時，備份也跟著消失，而且資料本身沒有開啟拒絕刪除的設定。技術名稱：未開啟刪除保護（no deletion protection）
預防方式
弄清楚你手上每一把金鑰實際能做什麼
確認每把金鑰的確切權限，並確認是否能限縮為有限用途。在得到確切答案前，請假設所有金鑰都能刪除你的系統，並把不再使用的金鑰全部移除。
不可以僅讓一個工具自行執行刪除指令
向供應商確認，刪除資料庫是否能設定為需要人工完成的動作（例如簡訊驗證或雙人核准）。若不行，請將擁有刪除權限的金鑰移出 AI 能觸及的範圍。
讓線上系統與練習副本使用不同的登入
將正式系統與測試系統放在不同的帳號下，各自擁有獨立的金鑰。和供應商書面確認：在測試區作業的 AI 工具，絕對無法觸碰到線上系統。
在另一家公司留一份你的資料副本
放在與正本同處的備份一律視為沒有備份。確認備份是否存放在另一家公司的儲存空間，確保一次刪除不會讓兩者一起消失，並每個月定期請人測試資料還原。
評估一把金鑰的危險程度，不在於你當初想讓它做什麼，而在於它最壞能造成什麼後果。