最近 AI agent 的討論很容易被一句話帶走：模型越來越會自己做事，所以風險越來越高。

這句話只對一半。

真正值得緊張的，不是 agent 會不會「像人一樣自主」，而是它到底拿到了哪些權限、能碰哪些資料、能不能替你送出表單、改 CRM、寄信、下單、部署、刪檔，以及這些動作發生後，有沒有人看得到、攔得住、救得回來。

也就是說，AI agent 的風險核心不是智商，是權限。

English TL;DR

The risky part of AI agents is not autonomy in the abstract. It is unclear permissions, weak logging, missing approval gates, and browser or SaaS access that lets agents act faster than governance can respond.

反直覺判斷：比較笨的 agent 也會造成大事故

很多人以為，只有超強模型才需要治理。模型越聰明，越可能失控；模型還不夠強，就先讓它多接工具、多跑流程，等真的有效再補安全。

這個順序很危險。

因為事故不一定來自模型「想太多」。更常見的情況是：模型誤讀了一段網頁內容、被間接 prompt injection 誘導、把測試環境當正式環境、把建議當命令、把舊流程當最新流程，然後剛好它手上有可以寫入的工具。

一個普通 agent，如果只能讀公開文件，最多產生爛摘要。另一個普通 agent，如果能登入後台、讀客戶資料、寄出郵件、更新訂單，它就算不聰明，也足夠危險。

所以企業導入 agent 時，最不該問的第一題是「哪個模型最強」。比較該先問的是：如果這個 agent 完全誤會任務，它最壞能做什麼？

瀏覽器 agent 會把老問題放大

今年 agentic browser、AI 瀏覽器擴充、WebMCP、桌面 agent 都在往同一個方向走：讓 AI 直接使用人類原本使用的工作介面。

這很有吸引力，因為它避開了漫長的後端整合。你不用替每個 SaaS 寫 API，只要讓 agent 會看網頁、點按鈕、填表單，很多工作看起來就能自動化。

但這也代表 agent 站在最混亂的邊界上：同一個瀏覽器裡有可信任的公司系統、不可信任的外部網頁、廣告、文件、郵件、留言、iframe、下載檔案。對人類來說，這些東西有直覺邊界；對 agent 來說，它們都可能變成上下文。

Google Chrome 團隊談 agent security 時，特別把 indirect prompt injection 視為瀏覽器 agent 的核心威脅之一。這不是學術潔癖，而是因為網頁本來就充滿未經審核的文字，而 agent 又會把文字變成行動依據。

如果 agent 只負責「看」，問題還小。當它開始「做」，瀏覽器就從閱讀工具變成自動化執行環境。

FAQ：那是不是不要用 agent？

不是。

比較務實的結論是：不要把 agent 當成新員工，要把它當成一個會犯錯、速度很快、記錄要完整的自動化流程。

新員工會問同事、看語氣、感覺不對會停一下；agent 不一定會。它可能在幾秒內完成十幾個步驟，而且每一步看起來都「有理由」。所以治理方式不能只靠一句「請小心」寫在 system prompt 裡。

第一步，列出工具清單。每個 agent 能用哪些工具、每個工具是只讀還是可寫、能碰哪些資料、是否能對外送出，都要明確寫下來。

第二步，把權限分級。查詢、草稿、內部更新、對外發送、金流、刪除、部署，不能放在同一個信任層級。越不可逆，越需要人審或二次確認。

第三步，保留 log。不要只記「agent 完成任務」，要記它看了什麼、呼叫了什麼工具、輸入參數是什麼、回傳結果是什麼、哪一步由人批准。

第四步，設計補救流程。寄錯信怎麼撤？資料改錯怎麼還原？工具 timeout 怎麼重跑？如果回答不出來，就先不要讓 agent 自動執行高風險動作。

給讀者的行動建議

如果你正在導入 AI agent，今天不要先開更多工具。先做一張「最壞情境表」。

把每個 agent 寫成一列，後面列出它能讀什麼、能寫什麼、能對誰發送、能不能花錢、能不能刪除、失敗時誰會知道。這張表做完，通常會比再看十篇模型評測更有價值。

AI agent 的成熟，不是它能不能自己完成任務，而是它做錯時，你的系統是否還像一個系統。

結論很簡單：別只追自主性，先管權限。真正能長期落地的 agent，不是最像人的那個，而是邊界最清楚、行動最可追蹤、出錯時最容易接手的那個。