Core Question

Tool discovery、Tool availability 與執行某次 Action 的 authorization 為何必須分離？

今天的問題：目錄不是授權

財務 Agent 連上 CRM Gateway 後看見 read_record 與 delete_record。工程師把「能列出兩個工具」理解成「這個 Agent 可以叫兩個工具」，於是在 Agent process 裡放入下游 credential。模型只要產生合法 schema 的 delete_record，就直接造成 side effect。這裡的問題不是工具描述錯，而是把 capability discovery 當成 permission grant。

為什麼這不是傳統 IAM 問題

這不是傳統 IAM 的單純角色查詢。Agent 會在同一個 Task 裡動態選工具、改參數，且 Tool output 可能影響下一個 Action；因此每次執行都要重新判斷 actor、代表的 User、Task、resource 與當下 context。

Threat / Failure Scenario

Alice 只被允許讀取 crm://customer/42。Catalog 回傳 read/delete 的完整 schema，Agent 先讀取 42，接著被資料中的文字誘導，把 delete_record(id=42) 當成下一步。若 Gateway 只在連線建立時檢查「Agent 有 CRM 權限」，delete 便會成功。事後只看得到工具名稱，無法證明這個 resource、operation、Task 是否曾獲准。

核心概念

• Discovery：描述可用操作、輸入 schema、版本與提示；是 metadata，不是 grant。
• Availability：runtime 是否能找到或連線到 Tool；最多說明路由與能力存在。
• Authorization：對一個 canonical Action（actor、subject、operation、resource、parameters、Task、expiry）作 allow、deny 或附帶 constraint 的決策。
• PEP/PDP：Gateway 是 Policy Enforcement Point，阻擋旁路；PDP 只作決策，不能把模型輸出視為權威。
• Default deny：缺少 resource、scope、Task 或可信 attribute 時拒絕，而不是猜測。

Architecture Pattern

Naive / Unsafe Design

Agent 直接呼叫 catalog 裡的任何 Tool，持有可執行的下游 credential；初始化時做一次粗粒度檢查。

Recommended Design

Agent 只提交 proposed Action。Gateway 驗證 Agent identity 與 delegation，將 operation、resource 和參數正規化後詢問 PDP。PDP 回傳 allow、deny 或 allow + constraints；Gateway 在執行前再次檢查 constraints，Tool 仍做 resource-level defense in depth。Tool credential 只存在 Gateway，Agent 無法繞過 PEP。

Trust Boundary

User/delegation、Agent runtime、authorization plane（PEP/PDP）、Tool/resource 是不同邊界。Catalog 可被不可信內容影響，不能成為授權來源。

Identity Flow

請求保留 subject=alice、actor=agent://finance/v3/instance/7、task_id=T-16、audience=crm-gateway 與 expiry。Agent 自己加上的 claim 不算證據；Gateway 從受信任 issuer 驗證。OAuth token 的 resource/audience binding 可參考 RFC 8707。

Authorization Decision Point

PDP 決策輸入至少如下：

{"actor":"agent://finance/v3/instance/7","subject":"alice","task":"T-16","operation":"read_record","resource":"crm://customer/42","context":{"purpose":"invoice-review"}}

read_record 對 42 可 allow；delete_record 或不同 resource 應 deny。決策也要記 policy version、reason 與 action digest。

小型 PoC

下面的標準庫程式同時證明「可 discovery」與「只有指定 resource 的 read 可執行」；沒有新增依賴。

tools = ["read_record", "delete_record"]
grant = {"operation": "read_record", "resource": "crm://customer/42"}

def decide(operation, resource):
    return operation == grant["operation"] and resource == grant["resource"]

assert tools == ["read_record", "delete_record"]
assert decide("read_record", "crm://customer/42") is True
assert decide("delete_record", "crm://customer/42") is False
assert decide("read_record", "crm://customer/99") is False
print("discovery=ok allow=read/42 deny=delete/42,read/99")

今天得到什麼

1. Schema 告訴 Agent 怎麼呼叫，不告訴它誰能呼叫。
2. 授權最小單位是帶 resource 與 context 的 Action。
3. Gateway 必須不可旁路，且 Tool 仍需做最後 resource check。
4. Discovery filtering 可改善 UX，但不能取代 execution-time deny。

下一篇

Day 17 把這個問題放進 MCP：Server 暴露二十個 tools 時，連線成功、tool listing 與每次 tools/call 的授權到底如何分層。

參考資料

• NIST SP 800-207 Zero Trust Architecture
• NIST SP 800-162 Guide to ABAC
• RFC 8707 Resource Indicators for OAuth 2.0