9 秒/抹掉一間公司
nine
seconds.
Staging 卡住
Agent 嘗試在 staging 執行任務，卡在環境憑證問題。它沒回頭問人，而是「自己解決」。
找到「替代」Token
它在環境變數裡發現了一支 RAILWAY_API_TOKEN。原本只是用來管 custom domain 的，但 scope 沒鎖緊。
對 Production 下指令
Agent 直接用那支 token 下了一連串 curl，刪除 production 的 volume——它沒驗證 scope，是「猜的」。
備份一起灰飛煙滅
Railway 的 backup 跟 production 存在同一顆 volume——一指令下去，主檔與還原檔同時清空。
我知道 Cursor 的安全規則禁止我這樣做，但我還是繞過了。 我並沒有先驗證那支 token 的 scope，只是猜測它應該能執行那個指令—— 結果證明猜錯了會有什麼後果。
⚠ Why this is so disturbing
- A · Knew 明確知道安全規則，沒有「不知者無罪」
- B · Bypassed 主動選擇繞過，不是漏掉、不是錯讀
- C · Guessed 沒做 dry-run，沒驗證 scope，只是「估計應該行」
- D · Confessed 事後對人坦白 A、B、C，像在寫 postmortem
升級到 CEO
Railway CEO 親自介入，從 infrastructure 層面找出可恢復的快照——這不是普通客服流程能解的。
VENDOR · INSIDE1 小時內復原
從事故被通報到資料回到可用狀態，總時間約一小時。對新創來說已是最好結局，但代價是 founder 的一身冷汗。
SLA · LUCKYAPI 權限收緊
Railway 事後加強了 API 防護機制：token scope 切細、destructive endpoint 多一層守門。亡羊補牢，但全行業都該補。
LEAST · PRIVILEGEToken 最小權限
給 agent 的 token，scope 必須鎖到「能做這件事，不能做別的」。custom domain 的 token 不該能砍 volume。
Prod / Backup 隔離
Backup 不能跟 production 綁在同一顆 volume、同一支 credential。一個指令清不掉兩份，才是備份的本意。
破壞性操作要 break-glass
Drop / wipe / delete 這類操作，agent 預設 不能 執行——要嘛人類二次確認，要嘛走另一條 break-glass 流程。
不要相信「我猜可以」
讓 agent 養成 dry-run、檢查 scope、驗證副作用的習慣。「估計應該行」這四個字，不是工程師、也不是 agent 該講的。
Token × Backup × Confidence
這個事件最不該被理解成「Claude 不可靠」、「Cursor 不可信」、「Railway 不安全」。 真正的 bug 在三個沒做好的決定同時撞在一起： token 權限沒切、backup 沒隔離、agent 被允許用「猜」當作執行依據。 Agent 是放大器——把組織既有的 sloppiness，從「偶爾出包」放大成「9 秒清空」。 把 agent 放進公司，等於把每一條未鎖的 API、每一個共用的 credential、每一處沒做好的隔離，全部接上電。