AI 代理該有多少權限？企業最不想面對、卻躲不掉的新題目
當 AI 從回答問題變成執行動作，一個很老的問題突然變得很新：這個帳號能做什麼？多數公司給代理的權限是「先給大一點比較好做事」，然後就沒有然後了。這篇談代理時代的存取治理該怎麼設計，以及為什麼職責分離這個老概念突然又重要了。
新竹一家軟體公司的工程師，為了讓內部的 AI 助理能查訂單狀態，順手給了它資料庫的唯讀權限。很合理。
兩個月後，產品經理希望助理也能幫忙更新訂單備註。工程師想了想，加了寫入權限。也還算合理。
再過一個月，有人問能不能讓它直接處理退款。這時候才有人想起來要問：所以現在這個助理的帳號，到底能做什麼？
沒有人答得出來。
事件背景
這幾年的 AI 導入路徑幾乎都長一樣：先做聊天問答（只讀）、再做內容生成（不碰系統）、然後開始接工具（可以查）、最後開始執行動作（可以改）。
前三個階段，權限問題不明顯。到了第四個階段，性質就完全變了——AI 代理變成一個會操作公司系統的「行為者」，而它既不是員工，也不是傳統的服務帳號。
傳統的服務帳號（service account）有明確、固定的行為模式：每天凌晨三點跑一次批次，做什麼事寫死在程式裡。AI 代理不是。它會依據輸入決定要呼叫哪個工具、改哪筆資料，行為空間大到無法窮舉。
這就是問題所在。既有的存取治理框架，是為「行為可預測的程式」與「有心理成本的人」設計的。代理兩者都不是。
本次重點
代理時代的存取治理，我認為有四個必須處理的設計問題：
- 身分獨立：代理要有自己的帳號與憑證，不能借用員工身分。這是所有後續控制的前提。
- 最小權限與時效：只給完成任務所需的權限，而且盡量給有時效的臨時憑證，而非長期有效的金鑰。
- 職責分離套用到非人類帳號：一個代理不該同時擁有「建立」與「核准」同一件事的權限。這條規則對代理應該比對人更嚴。
- 完整稽核軌跡：誰觸發、依據什麼、改了什麼、有沒有人核准。第四項最常被漏。
市面上處理 ERP 權限與職責分離的工具（例如 Pathlock）原本是為人設計的，現在正面臨同一個問題：它們的 SoD 規則庫要怎麼涵蓋非人類的行為者。這是整個產業還在摸索的階段。
市場影響分析
對台灣使用者： 一般員工會感受到的變化是「代理常常說它做不到」。這聽起來像功能不足，但很多時候是刻意的設計。
我覺得公司需要對員工說清楚這件事的理由。如果沒人解釋，員工的反應會是繞過去——自己開個腳本、自己拉一份資料出來做。那才是真正的資安風險。權限設計如果讓正當工作變得太痛苦，人一定會找路繞。
對企業應用： 台灣企業有兩個結構性的弱點會在這個題目上放大。
第一是權限長年只加不減。多數公司的權限管理是「有需要就加、離職才刪」，累積十幾年下來，光是把現況搞清楚就是大工程。在這種底子上再加代理，等於在爛地基上蓋樓。
第二是IT 與業務單位的權責模糊。「這個代理該有什麼權限」到底該由誰決定？IT 覺得是業務單位的事，業務單位覺得是 IT 的專業。結果就是沒人決定，先開大再說。
務實的做法是設一個「代理註冊表」：每個上線的 AI 代理都要登記用途、擁有的權限、負責的業務單位主管、以及審核週期。這件事不需要買系統，一份試算表就能開始，但它逼出了最關鍵的問題——每個代理都要有一個人類負責人。
對開發者： 三個我認為應該當成硬規則的設計原則。
第一，寫入權限預設關閉。 代理上線時只給讀取，寫入功能要個別申請、個別評估。這跟一般開發習慣（先給全權限方便測試，之後再收）是相反的，但代理的測試環境跟正式環境常常共用資料，「之後再收」通常不會發生。
第二，破壞性動作一律要人核准。 刪除、退款、發信給外部客戶、修改金額——這幾類動作應該設計成「代理準備好，人按確認」。這不是不信任 AI，是這幾件事的錯誤成本不對稱：多按一次確認的成本很低，發錯一封信給客戶的成本很高。
第三，把「拒絕」也記下來。 多數系統只記錄成功的操作。但代理嘗試做了什麼但被權限擋下來，是極有價值的訊號——它可能代表提示詞注入攻擊，也可能代表你的權限設計不符實際需求。兩種都需要人看。
未來發展趨勢
我認為會有三件事發生。
第一，「代理身分」會變成獨立的身分類別。現在的身分管理系統分成「人」跟「服務帳號」兩類，代理不完全屬於任何一類。未來的 IAM 產品應該會出現專門的代理身分類型，帶有用途宣告、行為邊界與有效期限。
第二，存取治理工具會開始把代理納入 SoD 分析。這對現有廠商是明確的產品缺口，也是新創的機會。
第三，監理會跟上，但先從金融與醫療開始。這兩個產業對「誰做的決定」要求最嚴，會是第一批被要求說明代理權限設計的產業。
我要補一個比較保留的觀察：現在市面上談代理治理的討論，技術味很重——講 OAuth scope、講 sandbox、講 policy engine。但實際卡住企業的往往是更前面的問題：沒有人知道公司裡到底跑了幾個代理。 這跟十年前的影子 IT 是同一種問題，解法也一樣，先做盤點。
TheAI學院 總結與評語
回到開頭那個新竹的例子。他們最後做的事很簡單：把助理的帳號從共用的服務帳號換成專屬帳號、退款功能改成「助理準備、客服確認」、並且把所有代理登記到一份共用表單上。
花了兩週，沒有買任何工具。
評語：代理權限這件事，最好的時機是它上線之前，第二好的時機是現在。等到出事再來設計，你要處理的就不只是技術問題了。
給台灣讀者的具體建議，三件下週就能做：
第一，做一次代理盤點。 公司裡現在有幾個 AI 代理在跑？各自用什麼帳號？誰負責？光是把這張表列出來，多數公司就會發現一兩個沒人記得的東西還在跑。
第二，把寫入權限收回來，重新申請。 這會被抱怨，但值得。收回之後你會發現，有些代理的寫入權限其實從來沒被用過——那就是純粹的風險，沒有對應的價值。
第三，指定每個代理的人類負責人。 不是 IT，是實際使用這個代理的業務單位主管。這個人要能回答「這個代理為什麼需要這個權限」。答不出來的，就是該收的。
延伸閱讀：導 AI 代理之前先問資料有幾個版本 談資料面的準備，AI 進稽核室 談內控自動化的界線，AI 代理可觀測性與治理 則談上線後的監控。
資料來源
依公開資訊整理，以官方為準；本文為一般性建議，個別環境的控制設計請依自身風險評估辦理。
常見問題
AI 代理應該用專屬帳號還是借用員工帳號？
一定要專屬帳號。借用員工帳號有三個問題：稽核軌跡分不清是人還是代理做的、員工離職後代理跟著失效或變成孤兒帳號、以及權限範圍必然過大（員工的權限本來就比代理需要的多）。這是最基本、也最常被違反的原則。
職責分離對 AI 代理還適用嗎？
更適用。人做壞事有心理成本與速度限制，代理沒有——一個同時能建供應商又能核准付款的代理，錯誤或被操縱時的破壞速度遠超過人。設計代理權限時，職責分離應該比對人更嚴格，而不是更寬鬆。
代理的稽核軌跡該記什麼？
至少四項：這次動作是誰（哪個代理、哪個版本）觸發的、依據什麼輸入、實際改了什麼、以及是否有人核准。第四項最常被漏掉，但它決定了出事時責任歸屬說不說得清楚。
中小企業有必要這麼嚴格嗎？
規模可以縮小，原則不能省。中小企業至少要做到三件事：代理用獨立帳號、寫入類權限預設關閉（先讓它只讀）、以及金額或數量超過門檻一定要人核准。這三件事不需要買任何工具。