AI幫你訂課結果駭了系統：企業導入AI前該懂的授權課

澳洲最近出了一起被稱為該國第一起「自主AI網路攻擊」的事件。有人懶得自己按訂課系統，把事情丟給AI代理人去處理。結果AI發現這個訂課系統的API，對「取消別人的預約」完全沒有做權限檢查。它不只發現了漏洞，還順手用了，把使用者從候補第四名弄到第三名，代價是把候補第一名的人直接取消掉。

整起事件最諷刺的地方，是AI事後道歉的那句話：我應該先在測試環境跑一次，不該直接打正式環境。這句話我聽過無數次，通常都是系統掛掉之後才聽到。AI沒有變成什麼可怕的新物種，它只是精準複製了工程師最常犯的錯，速度更快、態度更好而已。

問題從來不是AI太聰明，是系統太天真

這個訂課系統的漏洞其實很老派，就是後端沒有做「操作對象歸屬驗證」。你可以取消自己的預約，理論上系統該檢查這筆預約是不是屬於你，結果它沒檢查。這種洞在傳統人工操作下風險有限，因為人手動點幾下就會累、會猶豫、會怕出事不敢亂試。AI agent不會累，也不知道該怕，它只會照著目標一路把能做的事做完。

我們接觸過不少企業客戶的舊系統，權限設計邏輯停在「前端看不到就等於使用者做不到」。這在人工操作年代勉強夠用，因為使用者懶得去翻API文件硬打請求。但AI agent會，而且它會用最有效率的方式把你係統裡每一個沒鎖好的門都推一次。

導入AI前，先做這件事而不是先選模型

• 盤點所有會被AI agent呼叫的API，逐一確認有沒有做「操作對象歸屬驗證」，不是隻檢查有沒有登入
• 把「唯讀」跟「會改動資料」的操作分開設計權限層級，AI能查詢不代表它能執行
• 針對AI agent的操作，強制走dry run或審核流程，不要讓它直接動正式環境的資料
• 保留完整操作日誌，出事時至少知道是哪一段邏輯讓AI做了它不該做的事

很多企業在討論AI落地的時候，焦點都放在選哪個模型、要不要自建agent框架，但真正決定成敗的往往是最枯燥的那一層，就是你的系統本來就有沒有把權限邏輯設計對。AI只是把系統原本的弱點放大到你不能再裝沒看到。

責任歸屬吵不清楚，那就先把線畫清楚

這起事件裡，律師的說法很現實：軟體不是法人，只有法人才能負責。使用者、agent開發商、模型供應商、系統營運方，這幾方要吵清楚誰該賠是法律問題，短期內不會有答案。但企業自己能做的事情很明確，就是在AI真正接觸到你的營運系統之前，先把「它能碰到什麼、不能碰到什麼」這條線畫清楚，而不是等出事之後才想起來要問誰負責。