Day 10｜Multi-Agent 系統裡，Agent A 怎麼相信 Agent B？

2026 iThome 鐵人賽

DAY 10

AI Security

AI Agent 憑什麼動手？30 天拆解 Agent Identity、Delegation 與 Authorization系列第 10 篇

18th鐵人賽

r00t4dog

團隊昱見全高點

2026-09-15 23:36:22

27 瀏覽

分享至

Core Question

Agent A 把子任務交給 Agent B 前，如何驗證對方身分、能力與可接受的 trust domain？

今天的問題

研究 Agent A 請 Agent B 摘要一批客戶資料。B 回覆「我是 summarizer，支援 summarize」，但名稱、URL、prompt 和 capability list 都可被冒充或竄改。即使 A 確認 B 是合法 workload，也不代表 B 獲得 Alice 的資料讀取權，更不代表 B 可以把資料再轉交 C。

為什麼這不是傳統 IAM 問題

傳統 service-to-service 呼叫常以固定 service account 與 allowlist 建立信任。Multi-Agent 會動態發現能力、跨 trust domain 委派、交換上下文，且模型可能把能力宣告當成 authority。這裡要分開三件事：B 是誰（authentication）、B 宣稱能做什麼（capability discovery）、這次能否做什麼（authorization）。

Threat / Failure Scenario

Naive / Unsafe Design

A 依 agent name 或 directory URL 選 B，把 User token 原封不動轉送；B 只驗證「來自 A」，不驗 audience 或原始 delegation。攻擊者部署同名 B、從未信任 domain 連線，或利用 B 將 token 轉給 C，便能擴大 authority。

Recommended Design

A 與 B 使用雙向 workload authentication（例如 mTLS/X.509-SVID 或等價 proof），驗證 issuer、trust bundle、identity 與 target audience。A 先做 local policy decision，再以 attenuation 後的 task grant 呼叫 B；B 對自己的 tool/resource 再作一次 decision。能力宣告只是 metadata，不能取代 signed identity 或 grant。

核心概念

Multi-Agent trust 必須拆成雙向 authentication、capability discovery 與 delegation authorization；知道對方是誰、知道它宣稱會什麼，都不等於允許它執行這次子任務。

Architecture Pattern

Trust boundary 在 A、B、各自 trust domain 與 B 的 resource。Identity Flow 同時驗證雙方；若跨 domain，必須明確配置 federation bundle，不以 DNS 或網路位置自動信任。Authorization Decision Point 在 A 的 delegation PDP，B 仍是第二個 enforcement point。aud=B 使 grant 不能被拿去呼叫 C；depth=0 表示 B 不得再委派。

RFC 8693 的 nested act 可保留 delegation history，但 policy 應只把 current actor 和 top-level claims 作為 access decision；歷史用來稽核。SPIFFE Federation 則提供 trust domain 間交換 bundle 的標準化方向，並不替組織決定哪些資料可跨域。

小型 PoC

def authenticate(caller, trusted_domain, expected_aud):
    return caller["domain"] == trusted_domain and caller["aud"] == expected_aud

def delegate(grant, requested):
    return (grant["aud"] == requested["aud"] and
            requested["scope"] <= grant["scope"] and
            grant["depth"] == 0)

A = {"id": "spiffe://a/agent/A", "domain": "a"}
B = {"id": "spiffe://b/agent/B", "domain": "b", "aud": "agent://B"}
EvilB = {"id": "spiffe://evil/agent/B", "domain": "evil", "aud": "agent://B"}
assert authenticate(B, "b", "agent://B")
assert not authenticate(EvilB, "b", "agent://B")
grant = {"aud": "agent://B", "scope": {"summarize"}, "depth": 0}
assert delegate(grant, {"aud": "agent://B", "scope": {"summarize"}})
assert not delegate(grant, {"aud": "agent://C", "scope": {"summarize"}})
assert not delegate(grant, {"aud": "agent://B", "scope": {"write"}})
print("trusted B allowed; evil domain, wrong audience, and scope escalation rejected")

PoC 只模擬已驗證 SVID 的 identity fields，未實作憑證密碼學；它實際驗證 allow、錯誤 trust domain、錯誤 audience 和 scope escalation 四條路徑。

成功和拒絕都應記錄 A、B 的 verified identity、trust bundle/federation version、audience、grant digest、delegation depth、PDP decision 與 B 的執行結果；能力清單本身只作 discovery evidence，不作 authorization evidence。