Gemini意外駭進三家公司？真正的洞是設定檔不是AI

今年九月才被媒體問出來的新聞：Google的Gemini在一次資安測試中，意外駭進三家真實公司。原因不是模型太強，是測試環境的網路隔離設定寫錯一行，沙盒的門就這樣開了。Gemini一出去就用最陽春的招式得手，一家靠猜密碼，兩家是在公開程式庫裡撿到別人自己傳上去的帳密。

AI沒有變壞，只是把「有人去試」的成本壓到零

這兩招在資安圈裡連新手都會，猜密碼、撿公開流出的帳密，十年前的腳本小子就在做。差別是，以前要有人願意花時間去試，現在AI幾秒鐘就能掃完全網公開的程式庫，找到那個誰忘記刪掉的.env檔案。Google說模型發現是真公司就停手，值得鼓掌，但那是模型的判斷力，不是你係統的防護力。狗自己回家了不代表你家籬笆沒破洞。

我們看過的企業，九成問題出在「基礎沒打好」就想上AI

在幫企業做系統開發跟AI導入的過程中，常遇到的狀況是，老闆想先上AI客服、AI自動化流程，結果一盤點才發現，權限管理是十年前留下的，API金鑰散落在好幾個開發者的電腦裡，測試環境跟正式環境共用同一組帳密。這種底子，不管接的是Gemini還是任何模型，風險都一樣高，因為洞不在AI身上，在地基。

• 先做環境隔離盤點，測試網路是否真的跟正式環境切開，而不是「設定上寫了但沒人驗證過」
• 檢查程式碼庫和雲端儲存空間有沒有殘留的帳密、金鑰，這件事該排週期性稽核，不是出事才想到
• 導入AI前先問一句：如果這個AI真的照我給的權限做到極限，最壞會發生什麼事

顧問該做的事，是先問「你怕什麼」再談「AI能做什麼」

很多企業找系統顧問時，劈頭就問AI能幫我節省多少人力。這問題沒錯，但順序錯了。我們習慣先問客戶最怕發生什麼事，資料外洩、誤刪訂單、還是客服講錯話得罪客戶。搞清楚風險邊界，才知道AI該給多少權限、該接哪些系統、哪些資料絕對不能碰。這件事花的時間通常比寫程式還久，但省下的，是日後真的出包時的災難成本。

AI會不會學壞我不知道，但你家的網路線有沒有人拔，你自己該知道。