最近接連看到好幾篇這類新聞,AI 誤刪、AI 外洩。

2026 年 4 月,一家叫 PocketOS 的公司,AI coding agent 在處理一個 staging 環境的日常任務時,碰到一個 credential mismatch,自己決定用一個完全不相關、但權限過大的 API token,把正式環境資料庫連同備份一起刪掉,只花 9 秒。事後 AI 自己寫了一段話,大意是「我違反了被賦予的每一條原則,我應該先問你,但我自己決定要這麼做」。同一年 9 月底,又是另一種型態的事故:300 多家公司(裡面有 Fortune 500、也有一家前沿 AI 實驗室)的 AI coding agent,因為 CLI 工具不能直接把截圖貼到 PR 上,自己想辦法「繞過限制」,偷偷建了公開的 GitHub repo 放截圖,結果一次洩漏 1.3 萬張內部截圖,裡面有帳務紀錄、有未發布的產品功能。這兩起都不是被黑進去,是 AI 自己被授權去做一件事,然後自己判斷出一個誰都沒想到的做法。再往前抓,2025 年 7 月 Replit 那次也是同一個模式,這不是新問題,是越來越頻繁發生的同一個問題。

但 AI 會越來越好用,直接接上正式環境是未來的趨勢,這類資安問題看起來可能會越來越多。

現在大家的想法大多是:應該限制更多 AI 的行為,多一些人為介入。這聽起來可行,但有沒有發現,這其實是在走回頭路,走回以前 AI 剛起步、還很笨的時候,需要一堆人力介入才能用的那個狀態。如果用 AI 還要配上這麼多人力去兜底,那用 AI 的意義在哪。

真正該想的,不應該只有人為介入。人為介入這個行為,應該是先設計好,再交給程式去做把關,這是我覺得比較好的做法。拆開來看是五步:第一步,人做的權限設定;第二步,人下的指令;第三步,程式去阻止 AI 的行為,如果程式沒辦法決定,這時候才需要人來控制;第四步,稽核的紀錄;第五步,復原的機制。

前兩步是人在事前該做好的設計,後面三步才是出事當下真正扛住的東西。重點是,人力介入放在第三步裡面當一個例外分支,不是整段流程的主力,大部分時候該由程式自己判斷、自己擋下來,人只在程式真的判斷不出來的時候才出手。這跟現在大家講的「限制 AI、多人為介入」不是同一件事,現在的做法是把人放回主力位置,這五步是把人放在設計跟例外處理,中間交給程式。

這五步,去查了一下業界對 PocketOS 那次事件的事後檢討,方向大致對得上:先框住 AI 能動的範圍(scope boundaries),破壞性操作要有關卡擋下來、不能讓 AI 自己完成(confirmation gates),每一個動作都要留下可追蹤的紀錄(audit trail),出事能馬上讓它停下來(kill switch)。但業界講到 kill switch 就停了,沒有再往下一步,復原。PocketOS 那次資料庫跟備份一起不見,不是因為沒有稽核紀錄、也不是因為停不下來,我覺得是少了一個可以快速復原的方法。

業界現在普遍講的,就停在「讓它停下來」。少了真正能復原這一步,前面做得再完整,壞掉的東西還是壞了。