Core Question

Agent A 轉委派給 B 時，如何保留原始 User、限制 authority 並防止 privilege amplification？

今天的問題：子任務不是 Token 複製

Research Agent A 代表 Alice 找本季逾期客戶，將「只讀 customer_id 與 total_due、不得外送」的子任務交給 Report Agent B。若 A 直接把 Alice token 傳給 B，B 可能要求 write、讀取 payment_detail，甚至再轉交 C。A 需要建立的是一個比自己更窄、明確 audience 綁定 B 的新 delegation，而不是把原 Token 複製一份。

為什麼這不是傳統 IAM 問題

一般 service-to-service call 常只有 caller 與 callee；Multi-Agent 轉委派則要保留 Alice → A → B 的責任鏈，並讓每一跳都能驗證前一跳確實有權委派。Agent B 可能由不同團隊部署，且其輸出會改變下一步計畫，故 trust domain、depth 與不可再委派條件都必須進入 policy。

Threat / Failure Scenario

A 將 bearer User Token 放在 B 的 prompt 或 header。B 以同一 token 呼叫 write API，Tool 只看 sub=alice 而放行；事後 audit 看不到哪個 Agent 轉交，也無法判斷 B 是否超過 A 的 read-only task。這是 privilege amplification 與 accountability chain 遺失的組合失敗。

核心概念

• Delegation chain： 每一節記錄 delegator、delegate、audience、scope、task、expiry、depth 與 can_delegate。
• Attenuation： 子 grant 的權限集合只能是父 grant 的子集合。
• Audience binding： B 的 grant 不能拿去呼叫 A 或任意 Tool。
• Actor chain： 最終 Tool 可重建 Alice → A → B，而不是只看 Alice。

Architecture Pattern

Naive / Unsafe Design

A 將收到的 User Token passthrough 給 B，B 自行宣稱 scope，Tool 只驗 issuer、subject 與 API scope；沒有 chain、audience、depth 或 non-escalation check。

Recommended Design

A 向 delegation service 提出 exchange request，列出父 grant、B identity、目標 audience 與更窄 constraints。服務簽發新的 B grant；B 呼叫 Tool 時，PEP 驗證完整 chain、父子 scope 包含關係、expiry 與 can_delegate。

Trust Boundary

Alice/issuer、A runtime、delegation service、B runtime、Tool gateway 各自隔離。A 可以提出委派但不能簽發任意 authority；B 不能修改 chain 或刪除 actor history；Tool 不接受未經驗證的 X-Actor header。

Identity Flow

Authorization Decision Point

依 RFC 8693 的 token exchange 概念，交換不代表自動授權。PDP 要驗證 child.scope ⊆ parent.scope、child.audience 在父 grant allowlist、child.depth = parent.depth + 1、且 can_delegate=true。act/actor chain 可參考 RFC 8693 §4.1，但 chain retention 與業務 action 仍由本地 policy 決定。

小型 PoC

parent = {"scope":{"read_customer"}, "aud":"report-b", "can_delegate":True, "depth":0}

def exchange(parent, child_scope, audience, can_delegate=False):
    if not child_scope.issubset(parent["scope"]): return None
    if audience != parent["aud"]: return None
    if not parent["can_delegate"]: return None
    return {"scope":child_scope, "aud":audience, "can_delegate":can_delegate,
            "depth":parent["depth"] + 1, "chain":"alice>A>B"}

child = exchange(parent, {"read_customer"}, "report-b")
assert child and child["depth"] == 1
assert exchange(parent, {"write_customer"}, "report-b") is None
assert exchange(child, {"read_customer"}, "tool-c") is None
print("attenuation and audience checks: PASS")

PoC 的第二、三個案例分別證明 privilege amplification 與錯誤 audience 會被拒絕；正式實作還要以簽章、issuer key rotation 與防 replay 儲存保護 grant。

今天得到什麼

1. 轉委派是簽發新的、較窄的 authority，不是轉送 User Token。
2. 子 grant 必須保留原始 subject 與完整 actor chain。
3. scope、audience、depth、expiry 與 can_delegate 都是決策輸入。
4. B 即使是可信 Agent，也不能因能力宣告取得超過 A 的權限。

下一篇

Day 15 將處理 chain 的終點：哪些 audience、Action 或 trust domain 必須成為 terminal，讓 delegation 明確停止。

參考資料

• RFC 8693 — OAuth 2.0 Token Exchange
• RFC 8707 — OAuth 2.0 Resource Indicators
• NIST SP 800-207 — Zero Trust Architecture