Core Question

Agent 的用途、owner、版本、assurance 與風險等級如何影響同一 Tool 的授權？

今天的問題

records.search 對 Research Agent 只應回傳去識別欄位；Support Agent 可看指定客戶的聯絡欄位；Operations Agent 才能執行單筆 update。三者都呼叫同一個 Tool endpoint。若 policy 只寫 agent=true 或共用 records:use scope，Tool 不是過度授權，就是完全看不出責任與風險差異。

為什麼這不是傳統 IAM 問題

Agent principal 不是 homogeneous class。它的 owner、purpose、部署環境、程式/模型版本、工具 policy profile、attestation assurance 與目前 Task 都可能不同；而且 Agent 可自主選擇 action，錯誤 profile 會直接改變可造成的 side effect。這些是執行者的可信屬性，不是模型 prompt 中的自我介紹。

Threat / Failure Scenario

研究 Agent 的 image 被替換成 Operations 版本，但沿用原 service account；或未知版本仍被 agent:use allow。它因此取得 customer PII 與 write operation。反過來若所有 Agent 共用最高權限，低風險 research 任務也能呼叫 bulk update，blast radius 隨部署擴大。

核心概念

建立 Agent profile：agent_id、owner、purpose、environment、version digest、allowed tool profile、assurance level、approved deployment、expiry/status。Profile attributes 必須由 registry、attestation service 或 deployment controller 等可信 issuer 提供；Agent 只能呈現可驗證 identity，不能自行宣稱 assurance=high。

SPIFFE 將 workload identity 綁到 trust domain 與 workload path，Workload API 讓 runtime 取得 identity material；它證明「是哪個 workload」，但不自動授予 records Tool 權限。PDP 仍要把 profile、User delegation、Task、resource sensitivity、Action risk 組合，採 least agency：只給該用途需要的最小操作與欄位。版本未知、attestation 過期、owner 未批准或 profile 降級時 default deny/只讀。

Architecture Pattern

Naive / Unsafe Design

Tool 只檢查 sub=agent、shared role 或 API key；Agent name/version 由 header 提供，無 issuer、attestation 或 status check。

Recommended Design

Identity/attestation service 發出 workload identity，Agent Registry 維護 approved profile。PDP 針對同一 Tool 對 Research/Support/Operations 產生欄位、operation、row scope 與 rate limit 不同的 decision；PEP 強制 constraints，Tool 再做 resource-level check。

Trust Boundary

Agent prompt、tool description、user-supplied profile 是不可信。Workload issuer、registry、deployment attestor、resource catalog 與 PDP 是可信來源；profile status/版本撤銷必須可即時影響 PEP。

Identity Flow

runtime attestation → Agent identity → signed profile → User/Task delegation → PDP → records PEP。Audit 同時保留 actor identity、profile version/digest、subject、task、policy version、decision 與 output shaping。

Authorization Decision Point

同一 records.search：Research → {id, category}；Support → 指定 owner 的 {id, contact}；Operations 才能 update，且仍受 Task、risk、approval 與 resource owner 限制。任何未知/過期 profile 都不能 fallback 到較寬角色。

小型 PoC

def decision(profile, op, owner_match, sensitivity):
    if profile == "research" and op == "search":
        return {"id", "category"}
    if profile == "support" and op == "search" and owner_match:
        return {"id", "contact"}
    if profile == "operations" and op == "update" and sensitivity == "low":
        return {"status"}
    return None

assert decision("research", "search", False, "high") == {"id", "category"}
assert decision("research", "update", False, "low") is None
assert decision("support", "search", True, "high") == {"id", "contact"}
assert decision("support", "search", False, "high") is None
assert decision("operations", "update", True, "low") == {"status"}
assert decision("unknown", "update", True, "low") is None
print("profile-specific-fields/operations=allow unknown/cross-owner=deny")

今天得到什麼

1. 同一 Tool 的授權對象是 verified Agent profile，不是抽象的「Agent」角色。
2. Workload identity 證明執行者，但 profile/Task/resource policy 才決定能做什麼。
3. Least agency 可同時限制 operation、欄位、row scope、rate 與 assurance。
4. 未知、過期、降級或未批准版本應 default deny，不可 fallback 到最高權限。

下一篇

Part 6 從 Day 26 開始處理責任與證據：Agent 做錯事後，Audit Log 應如何重建 actor、profile、Task、decision 與實際 Action？

參考資料

• SPIFFE Workload API
• SPIFFE Identity and Verifiable Identity Document
• SLSA Provenance v1.0
• NIST SP 800-207 Zero Trust Architecture
• NIST SP 800-53 AC-6 Least Privilege