Least Agency

資料來源#

• Zero Trust for AI Agents

摘要#

Least agency 是由 OWASP 提出的術語，它將經典的 least-privilege 原則延伸至 agentic 應用。least privilege 約束的是 使用者與系統能存取什麼，而 least agency 更進一步：它限制 每個 agent 工具能做什麼、能做多頻繁，以及能在哪裡執行。 它是 Zero Trust for AI Agents 的核心授權原則——也是對「即使是通過完美驗證的 agent，一旦被授予過多權限仍會造成損害」這個問題的務實解答。

與 least privilege 的區別#

傳統的 least privilege 關注的是 存取範圍（某個身分能接觸哪些資源）。一旦某個身分能自主地串連多個操作，動作 與 頻率 這兩個維度便變得重要，而 least agency 正是補上了這兩者：

• 資料庫工具只取得 read-only 查詢權限（而非寫入／刪除）
• 電子郵件摘要工具不取得 發送／刪除 權限
• API 整合只取得 最小限度的 CRUD 操作

這個轉變之所以重要，是因為 agent 雖在其被授予的權限 範圍內 運作，卻仍可能被操弄而濫用這些權限——這正是傳統存取控制無法防範的 tool-misuse 與 tool-chaining 威脅（攻擊面向請見 Agentic Prompt Injection 與 Agent Supply Chain Risk）。least agency 縮減的是 即使持有有效憑證 仍可觸及的有害動作集合。

框架如何落實#

least agency 透過存取控制的層級階梯（tier ladder），以及實作流程的 Phase 3/5 來落實：

• Deny-by-default — 封鎖所有未經明確授予的存取；將其視為起始態勢，而非終點。
• Permission models — RBAC（Foundation）→ 具備 context-aware policies 的 ABAC（Enterprise）→ 針對每個動作重新評估的 continuous authorization（Advanced）。
• Privilege scoping — 靜態的 least-privilege roles（Foundation）→ 針對每項任務 dynamic elevation 並 return-to-baseline（Enterprise）→ 具備自動過期的 JIT/JEA（Advanced）。「當有疑慮時，優先選擇能 移除 某項能力的控制，而非僅僅 節流 它的控制。」
• Capability restrictions — 一個被限制為僅能讀取的電子郵件工具，其發送功能需要另行授權；一個能查詢但無法變更 schema 的資料庫工具。
• Compartmentalization — 將一個 agent 的功能拆分到多個 agent，每個 agent 各自擁有專屬的 identity 與 credentials，使得攻擊者必須攻破數個 agent 才能觸及更多資源。「如果你把它拆成多個 agent 卻給它們全部相同的 credentials，那你就沒能把風險區隔開來。」

與 blast radius 的關係#

least agency 是 輸入 控制；Blast Radius (Agentic) 則是 結果 指標。約束 agency（動作 × 頻率 × 範圍）正是縮減 blast radius 的方式——而「assume breach」態勢預期 blast radius 終將受到考驗。兩者需合併解讀：將一個 agent 的帳號範圍限縮為僅對它所需的資料具備 read-only 權限，被竊取憑證的 blast radius 便會「受到嚴格限制」。

相關連結#

• Zero Trust for AI Agents — 採用 least agency 作為其授權原則的框架（樞紐）
• Blast Radius (Agentic) — least agency 是約束它的方法；agency 進、blast-radius 出
• Agent Identity and Authentication — 若沒有各自獨立的 per-agent identity，least agency 便無從落實（「attribution gap」使落實成為不可能）
• OWASP — 提出此術語者
• Claude Code Best Practices — Claude Code 的 deny-by-default 權限與寫入存取限制，正是此處所引用的參考實作
• Agentic Prompt Injection — least agency 所要遏制的攻擊：被操弄的 agent 在授權範圍內濫用工具
• Impossible, Not Tedious (Design Test) — 「優先移除能力而非節流它」正是 least agency 以設計啟發法形式呈現的表達
• MCP and Computer Use — 每個 MCP 工具的 capability restrictions（read-only、no-send）正是工具介面層級的 least agency
• Autonomous Defense — 將 least agency 向內 套用於防禦型 agent：具備明確邊界的範圍化自動回應動作
• Agent Supply Chain Risk — 限縮一個（可能已遭下毒的）工具能做什麼，便能限制被入侵的相依套件所能造成的損害
• Foundation → Enterprise → Advanced: Is the Agent Access-Control Jump a Cliff? — RBAC→ABAC→continuous-authorization 與 static→dynamic→JIT 這兩道階梯各自落在何處；Enterprise 中點，以及 ABAC 層級定位的矛盾

開放問題#

• least agency 加入了一個 頻率 維度（「多頻繁」），但框架同時也說 rate limits 是摩擦，而非屏障（Impossible, Not Tedious (Design Test)）。頻率限制如何能同時既是 least-agency 控制、又只是製造摩擦的手段——是否取決於情境？
• Dynamic privilege elevation（Enterprise）重新引入了一條 elevation 路徑；面對一個被操弄的 agent，這個 elevation 請求本身又該如何驗證？

資料來源#

• Zero Trust for AI Agents — least agency 定義於 Part I；並在 Part III 的存取控制層級與 Part IV 的 Phase 3 與 Phase 5 中落實