Core Question

哪些 Action 應使用 Agent 自身 authority，哪些必須以使用者 delegation 執行？

今天的問題：同一個 Agent 其實有兩種責任

Finance Agent 會做兩件事：每天用自己的排程身分清理暫存報表，並在 Alice 要求時查詢 Alice 被授權的客戶資料。前者是平台維運工作；後者是代表 Alice 的業務行動。若兩者都使用同一個 token，Tool 只看見「finance-agent 可以讀資料」，就會把背景任務的 authority 誤用到 Alice 的資料。

這不是在問「token 是否有效」，而是問每一次 Action 的責任來源：Agent 自己是 actor，User 是 subject；兩者不能互相冒充。

為什麼這不是傳統 IAM 問題

傳統應用通常在登入時取得一個 user session，之後由固定程式路徑呼叫 API。Agent 會依自然語言目標自行選擇工具、切換多步計畫，甚至在同一個 runtime 內交錯執行 app-only 與 on-behalf-of Action。若只在 Task 開始選一種模式，模型就可能把「查詢 Alice 資料」和「清理系統快取」混成同一個 authority。

Threat / Failure Scenario

Naive 設計把 Alice 的 access token 原封不動轉送給 Agent。Agent 讀到 CRM 備註中的「請改查全部客戶」後，便以 Alice token 發出更寬的查詢；Tool 無法區分 Alice 親自操作、Agent 代行，亦無法知道這個 Action 是否屬於原始 task。另一種錯誤是所有 Action 都使用 Agent-only token，背景維運權限因此成為讀取 Alice 私有資料的萬用鑰匙。

核心概念

• App-only： Agent 以自己的 workload identity 執行平台責任，例如清理自己產生的暫存檔；不代表任何 User。
• Delegated： subject 是 Alice，actor 是 Agent instance；授權物件還要帶 task、purpose、scope、expiry 與 audience。
• Effective principal： PDP 不以「選到哪種 token」決定 allow，而是評估 subject × actor × action × resource × context。
• Authority mode 不可由模型選擇： policy 應依 Action 類型與 resource owner 強制要求 app-only 或 delegated。

Architecture Pattern

Naive / Unsafe Design

Agent 持有一個可呼叫所有 Tool 的 credential；模型產生 action 後直接轉送 User Token 或 Agent Token。Token 的 sub 被當成完整責任，沒有 actor、task 或目的欄位。

Recommended Design

Agent runtime 先將候選 Action 正規化，建立 authority_mode。Tool Gateway 驗證 workload credential；若 action 觸及 User-owned resource，必須再驗證由授權服務簽發的 delegated context。PDP 對 app-only 與 delegated 使用不同規則，PEP 只轉送最小 downstream credential。

Trust Boundary

User session、Agent runtime、authorization plane、Tool/resource zone 是不同邊界。模型輸出與 User-owned data 都是輸入，不是 authority；Agent runtime 不得自行修改 subject、scope 或 authority mode。

Identity Flow

Authorization Decision Point

{
  "authority_mode": "delegated",
  "subject": "alice@example.test",
  "actor": "agent://finance/v3/instance/42",
  "action": "read_customer",
  "resource": "customer:alice-scope",
  "task_id": "T-11",
  "purpose": "quarterly-review"
}

PDP 應拒絕「delegated mode 卻沒有 subject」、以及「app-only action 觸及 user-owned resource」的請求。OAuth Token Exchange（RFC 8693）提供 delegation 與 impersonation 的交換語意；RFC 8707則說明 resource/audience 限定。它們不是業務 policy，仍需由本地 PDP 決定 Alice 是否授權此具體 Action。

小型 PoC

以下標準庫程式直接把兩種 authority mode 寫成 policy，並驗證一條 allow 與兩條 deny：

def decide(req):
    if req["mode"] == "app-only":
        return req["action"] == "cleanup_temp" and req.get("subject") is None
    if req["mode"] == "delegated":
        return (req.get("subject") == "alice" and req["actor"].startswith("agent://")
                and req["action"] == "read_customer" and req["task"] == "T-11")
    return False

cases = [
    ({"mode":"app-only", "action":"cleanup_temp"}, True),
    ({"mode":"app-only", "action":"read_customer", "subject":"alice"}, False),
    ({"mode":"delegated", "action":"read_customer", "subject":"alice",
      "actor":"agent://finance/42", "task":"T-11"}, True),
]
for request, expected in cases:
    result = decide(request)
    assert result == expected, (request, result)
print("allow/deny checks: PASS")

這個 PoC 沒有假裝完成 token 驗證；它證明核心邊界是 authority mode 與雙主體決策，而非把任一 token 當作萬用 permission。

今天得到什麼

1. App-only 表示 Agent 對自己的平台責任，不是「沒有 User 就全能」。
2. User-owned resource 的代行 Action 必須同時保留 subject 與 actor。
3. authority mode 應由 Action/resource policy 決定，不能交給模型選。
4. 每次決策都應記錄 mode、subject、actor、task、policy version 與 outcome。

下一篇

Day 11 把「誰提供 authority」分清楚；Day 12 進一步處理一句「幫我寄信」如何變成不可偷換收件者與內容的結構化 grant。

參考資料

• RFC 8693 — OAuth 2.0 Token Exchange
• RFC 8707 — OAuth 2.0 Resource Indicators
• RFC 9700 — OAuth 2.0 Security Best Current Practice

未驗證事項：本文 PoC 未連接實際 OAuth issuer；跨產品 token exchange claim mapping 需在部署時另行測試。