AI Agent 最小權限實踐：能力標籤驅動的授權模型 · 行業洞察

「先跑起來」的技術債

Agent 接入的典型路徑是這樣的：給它一個能用的令牌，讓它把流程跑通，驗證價值，然後投入使用。

這個路徑本身沒錯——先驗證價值是合理的工程判斷。問題在於第二步：幾乎沒有團隊回頭收緊過權限。 那個為了調試方便給的組織級令牌，一路跟着 Agent 進了生產。

後果不是理論上的。Agent 的行為由模型動態決定，而不是由代碼固定。這意味着「它現在能做什麼」和「它將來會做什麼」之間沒有確定的映射——當它擁有超出任務所需的權限時，你實際上是在依賴模型的判斷力做安全邊界。而模型的判斷力，正是提示詞注入攻擊的目標。

企業已有成熟的身份與訪問管理體系，直接套用到 Agent 上卻會遇到三個錯配：

主體不穩定。 傳統 IAM 假設主體（用户、服務）的行為模式相對固定。Agent 的行為隨任務、隨上下文、隨模型版本變化，用靜態角色描述它天然不準。

權限粒度錯位。 IAM 通常按資源和操作授權（「可讀取 S3 桶 X」）。而 Agent 的風險單元是能力（「能讀取任意本地文件」、「能發起外部網絡請求」）——同一個能力可能橫跨多個工具和資源，而同一個工具可能同時具備多種能力。

授權時機不同。 傳統授權是接入時的一次性決策。Agent 生態中工具隨時增刪、MCP Server 靜默更新，權限面在持續變化，需要的是持續評估而非一次審批。

可行的做法是在工具與權限之間插入一層抽象：能力標籤。

不去問「這個 MCP Server 叫什麼名字」，而是問「它啓用後，Agent 會獲得哪些能力」，並把答案標準化成一組標籤。典型的能力域包括：

這套標籤的價值在於可比較、可策略化。你可以規定「任何帶 shell 執行標籤的工具必須走人工審批」，而不必逐個工具討論；也可以在工具更新後重新打標籤，用標籤變化觸發重新評估——聲明的能力變了，説明風險面變了。

一、按任務授權，不按工具授權。

先定義 Agent 要完成的任務需要哪些能力，再據此挑選工具與憑證。這個順序很關鍵：反過來（先挑工具、再看它要什麼權限）幾乎必然導致過度授權，因為工具作者總傾向於要更多權限以覆蓋更多場景。

二、警惕能力組合。

單個能力可能無害，組合起來則不然。「讀取本地文件」加「發起外部網絡請求」，等於數據外傳能力；「讀取環境變量」加「執行 shell」，等於憑證竊取加橫向移動。授權評估必須看能力集合的交互，而不是逐項打勾。

這正是很多實際事故的成因：每一個工具單獨看都合理，湊在一起就打開了一條完整的攻擊鏈。

三、不可逆動作單獨把關。

刪除、支付、對外發送、生產配置變更——這類動作的共同點是出錯無法撤銷。它們應該從常規權限中剝離出來，要求顯式確認或獨立審批，無論 Agent 有多「可信」。

接入時：對每個工具/MCP Server 做能力審計，產出標籤集，比對聲明與實現（工具説自己只讀日曆，實現裏卻有文件寫入能力——這種不一致本身就是風險信號）。據此產出 block / need_review / pass 判定。

運行時：憑證按 Agent、按任務隔離，作用域最小化，且可獨立吊銷。網絡出口白名單作為兜底——即使工具被投毒，數據也出不去。

持續：記錄 Agent 的實際工具調用，與授權範圍比對。長期未被使用的能力應當回收——這是最容易被忽略、但成本最低的收緊手段。工具版本變化時觸發重新評估。

Agent 安全的核心問題正在從「這個工具是不是惡意的」轉向「這個工具被啓用後，Agent 會獲得哪些需要審批的能力」。前者是惡意檢測的問題，後者是能力審計的問題——而企業的准入決策，需要的是後者的答案。

這也是 SkillSec 的方法論基礎：把 Agent 生態的組件（Skills、MCP Server）按能力域拆解，用分級證據支撐判定，讓權限決策建立在「它能做什麼」而不是「它看起來像不像壞人」之上。

最小權限不是新概念，它只是在 Agent 場景下變得更難、也更重要——因為這一次，被授權的主體會自己決定做什麼。

---