Core Question

一次代行 Action 應如何同時保留 User intent、Agent executor 與部署方責任？

今天的問題

想像公司裡有一個「專案助理 Agent」。Alice 對它說：

整理客戶今天的回覆，寄給專案團隊，提醒大家明早以前確認。

Agent 讀取 CRM、產生摘要、從通訊錄找出它認為的「專案團隊」，最後呼叫寄信 Tool。信件成功寄出，但其中一個群組其實包含外部顧問，客戶尚未公開的報價因此外流。

事故調查時，大家很快會遇到一個看似簡單、實際上答不完的問題：

• 是 Alice 下的指令，所以 Alice 負責？
• 是 Agent 選錯收件者，所以 Agent 是執行者？
• 是平台團隊部署了這個 Agent，所以平台 operator 負責？
• 寄送前若有人按過核准，那位 approver 要承擔全部責任嗎？

這些答案都只說對一部分。一次 Agent Action 通常同時存在「誰發起」、「以誰的權限為基礎」、「誰實際送出請求」、「誰核准」、「誰營運系統」與「結果發生後由誰處理」等不同角色。若把它們壓成 audit log 裡的一個 user_id，事後就只能找一個人背鍋，無法還原責任鏈。

本篇談的是 accountability architecture：系統要留下哪些 identity、delegation、decision 與 outcome evidence，才能回答誰在什麼角色下影響了這次 Action。它不是法律責任判定；法律與勞動、契約、產業監管的歸責仍須由組織依適用規範處理。

為什麼這不是傳統 IAM 問題

傳統的 delegated application 也會代表使用者呼叫 API，但 Agent 又多了一段會改變結果的執行鏈：自然語言 intent 先被模型解讀，再由 Agent 規劃步驟、選 Tool、組參數，甚至根據中途結果改寫後續 Action。

在剛才的例子裡，Alice 並沒有逐字指定：

send_email(
  recipients=["project-all@example.com"],
  attachment="customer-summary.md",
  classification="confidential"
)

她提供的是目標，不是完整 API request。真正跨越安全邊界的是 Agent 後來具體化的 Action。因此即使 Alice 已通過登入、也確實有寄信權限，仍有三個傳統 User → Application → API 圖很容易藏起來的落差：

1. Intent gap：User 說的目標與 Agent 組出的具體參數不完全相同。
2. Execution gap：Tool 的直接 caller 是 Agent workload，不是坐在畫面前的 User。
3. Outcome gap：API 回傳成功，不代表副作用符合 User 原始目的，也不代表資料送到了正確邊界內。

所以「User 通過 authentication」只回答 User 是誰；「Agent 有 access token」只證明某個 caller 帶著 credential。兩者都沒有單獨回答：這個 Agent 現在代表誰、這個具體 Action 為何被允許，以及實際結果由誰承接。

Threat / Failure Scenario

我們把事故現場的 audit log 分成三種常見設計。

Failure 1：只記 User

{
  "user": "alice",
  "operation": "send_email",
  "result": "success"
}

這筆紀錄讓人誤以為 Alice 親自選擇收件者並送信。它無法回答是哪個 Agent deployment、哪個 runtime instance、哪個版本的 planner 產生 Action，也無法區分 Alice 的原始 intent 和 Agent 補出的參數。

Failure 2：只記 Agent

{
  "service_account": "project-assistant",
  "operation": "send_email",
  "result": "success"
}

這次看得到 workload，卻不知道它是否代表 Alice、執行背景排程，或使用平台自己的 app-only authority。也看不出 Alice 是否真的委派過寄信，還是 Agent 拿先前殘留的 credential 自行重試。

Failure 3：有 approval ID，卻沒綁定 Action

{
  "user": "alice",
  "agent": "project-assistant",
  "approval_id": "ap-2048",
  "operation": "send_email",
  "result": "success"
}

如果 approval 只表示「有人按過同意」，沒有綁定收件者、內容摘要、資料分類、期限與 Action digest，就無法證明核准的是最後送出的那封信。Agent 在核准後改了參數，log 看起來仍然一切合法。

這三種設計的共同問題不是 log 太少，而是把不同責任角色壓成單一 principal，並把「API 成功」誤當成「行為合理」。

核心概念

責任不是二選一，而是一條 chain

W3C PROV 的 provenance model 提供了一個很好的語意起點：一個 Agent 可以 actedOnBehalfOf 另一個 Agent，而被代表的一方仍保留某種 outcome responsibility。它也允許同一 Activity 與多個 Agent 建立關聯。這正適合提醒我們：delegation 不是把責任從 A 搬走、全部丟給 B。W3C PROV-O

在企業 Agent Action 中，至少應區分以下六個角色：

同一個人可能同時扮演兩個角色，例如 Alice 既是 initiator 也是 subject；但 schema 仍應分欄記錄，不能因這次值相同就合併概念。反過來，approver 也不會因按下核准就自動變成 actor 或 operator。

Subject 與 Actor 必須同時存在

RFC 8693 OAuth 2.0 Token Exchange 將 subject_token 描述為「代表被代行一方身分的 token」，將 actor_token 描述為「代表 acting party 身分的 token」。同一份規格的 act claim 則能在 JWT 中表達 authority 已發生 delegation，並識別目前 actor；巢狀 act 還可記下先前的 delegation chain。

套到 Agent：

{
  "sub": "user:alice",
  "act": {
    "sub": "agent:project-assistant/instance-7f3a"
  },
  "aud": "tool:mail-gateway",
  "scope": "mail.send"
}

這段只是示意，不是宣告一套新的標準 claims profile。重點是 Tool 同時看得到：

• top-level sub：被代表的 subject；
• act.sub：目前真正呼叫 Tool 的 actor；
• aud：這份 token 預定交給哪個服務處理；
• scope 與其他 constraints：被交付的 authority 上限。

還要注意 RFC 8693 的限制：較早的 nested actors 是歷史資訊，不應直接拿來作當前 access-control decision。Delegation history 能協助調查，不等於鏈上每一個 principal 都自動取得權限。

Identity claim 不是責任判決書

JWT 的 sub、act 或 client_id 可以傳遞身分語意，卻不會回答以下問題：

• User 的自然語言是否被正確轉成這組 Action parameters？
• Operator 是否部署了未經評估的新版本？
• Approver 是否看過與實際執行完全相同的內容？
• Tool 回傳成功後，Resource 真正發生了什麼 side effect？

換句話說，token 是 decision input 與 evidence 的一部分，不是「責任全歸 sub」的機器可讀免責條款。NIST AI RMF 也把清楚的 organizational roles、responsibilities 與 accountability mechanisms 視為治理要求；不同 AI lifecycle actors 會因角色而有不同責任，而不是由單一技術元件承擔一切。NIST AI RMF 1.0

錯誤、越權與合法執行，要找的是不同控制點

Accountability chain 的目的不是讓每次事件都平均分責任，而是避免只憑最後結果倒推「一定是 User」或「一定是 AI」。同一組角色在不同 failure mode 下，應接受檢查的控制點不同：

這張表仍不直接宣告個人的法律過失；它把調查從「誰最後碰到系統」轉成「哪個角色應控制哪個環節、證據顯示哪裡偏離」。

從 User intent 一路記到 Resource outcome

要能事後回答責任問題，evidence 至少要覆蓋下面七個 checkpoint：

NIST SP 800-53 Rev. 5 的 AU-3 要求 audit record 至少能建立事件類型、時間、位置、來源、結果，以及相關 user / subject 身分；對 Agent 系統而言，這是最低線而非完整答案，因為我們還要加上 actor、delegation、policy 與 Action binding。NIST SP 800-53 Rev. 5

Architecture Pattern

Naive / Unsafe Design

User Token ──> Agent ──> Tool
                 │
                 └── log: user=alice, result=success

這個設計讓 Agent 直接重用 User credential，Tool 只看 sub=alice。其後果是：

• Agent workload identity 消失，無法確認哪個 instance 真正呼叫 Tool；
• User intent 與 Agent 產生的 Action 沒有可驗證連結；
• approval 與執行參數可能發生 approve-one-execute-another；
• Operator 的 deployment / policy change 不在 Action evidence 中；
• Tool success 沒有連到 Resource side effect。

Recommended Design

這個設計沒有假裝一張圖可以決定「誰負全部責任」。它做的是讓每一個角色在 Action lifecycle 中留下可關聯、不可任意互換的 evidence。

Trust Boundary

圖上至少有四個邊界：

1. Identity and Delegation Boundary 驗證 User 與 Agent 各自的 identity，發出有期限與 audience 的 delegation context。
2. Agent Runtime Boundary 是不完全可信的決策環境。模型可以提出 Action，但它的輸出不是 authority。
3. Authorization Boundary 將自然語言以外的結構化 Action 交給 PDP 決策，並由 PEP 執行 constraints。
4. Execution Boundary 由 Tool 與 Resource 落實 operation-level 與 resource-level 控制，回報真實 side effect。

任何 authority 或資料跨越邊界，都應帶著接收方能獨立驗證的 context；不能只相信 Agent 自報「Alice 叫我做的」。

Identity Flow

一條可歸責的寄信 flow 可以是：

1. Alice 完成 authentication，系統建立 User Identity 與 task_id。
2. Agent runtime 以自己的 workload / instance identity 啟動；operator 與 deployment metadata 可被追溯。
3. Authorization service 建立 delegation context：subject=Alice、actor=Agent instance、允許的目的與期限。
4. Agent 把自然語言 intent 具體化成結構化 Action，包括 recipients、content digest 與資料分類。
5. PDP 同時評估 subject entitlement、actor assurance、delegation constraints、Action、Resource、risk 與 environment。
6. 若政策要求人類核准，approver 看到具體 Action；approval evidence 綁定 Action digest 與有效期。
7. Tool Gateway 驗證 identity、decision / approval 與 Action 一致後才轉送，Tool 再做 resource-level enforcement。
8. Tool result 與 Resource 實際 side effect 以同一 task_id、action_id、trace_id 關聯回 evidence plane。

OpenTelemetry Logs specification 說明了用 TraceId、SpanId 把分散元件的 log 與 trace 關聯起來的價值。不過 correlation 只代表「這些事件屬於同一次 execution context」，不等於已證明授權正確；policy decision、Action digest 與 outcome evidence 仍要由應用層明確記錄。

Authorization Decision Point

PDP 不應只問 subject=Alice 是否有 mail.send。它至少要評估：

subject     = user:alice
actor       = agent:project-assistant/instance-7f3a
delegation  = task-2026-0042, purpose=project-update, expires=...
action      = mail.send, recipients=[...], content_digest=...
resource    = mailbox:alice, data_classification=confidential
approval    = approver:bob, action_digest=..., expires=...
environment = time, network zone, risk signals

決策結果也不該只有 boolean。它可以是 deny、allow_with_constraints 或 approval_required，並附上可執行的 obligations，例如只允許公司網域收件者、移除 confidential attachment、限制寄送一次，或要求重新核准。

更重要的是：PDP 的 allow 表示當時輸入符合某版 policy，不表示所有相關人員從此免責。 若 operator 配錯 policy、Agent 執行的 Action 和送審版本不同，或 Tool 忽略 constraint，仍可沿 evidence chain 找到各自的控制失效點。

小型 PoC

這個 PoC 不啟動 Identity Provider，也不新增 dependency。它只用 Python standard library 比較三種寄信事件，檢查事故調查所需欄位是否齊全。

from hashlib import sha256
import json


def digest(value):
    canonical = json.dumps(value, sort_keys=True, separators=(",", ":"))
    return sha256(canonical.encode()).hexdigest()


action = {
    "operation": "mail.send",
    "recipients": ["project-team@example.com"],
    "content_digest": "sha256:summary-v3",
    "classification": "confidential",
}

user_only = {
    "task_id": "task-2026-0042",
    "initiator": "user:alice",
    "subject": "user:alice",
    "action": action,
    "outcome": {"status": "success"},
}

agent_only = {
    "task_id": "task-2026-0042",
    "actor": "agent:project-assistant/instance-7f3a",
    "action": action,
    "outcome": {"status": "success"},
}

dual_subject_actor = {
    "task_id": "task-2026-0042",
    "action_id": "action-0007",
    "trace_id": "4fd0c8c9d5e64dd69c4a2b66e24c45e2",
    "initiator": "user:alice",
    "subject": "user:alice",
    "actor": "agent:project-assistant/instance-7f3a",
    "operator": "team:ai-platform",
    "delegation": {
        "purpose": "project-update",
        "expires_at": "2026-08-12T10:05:00Z",
    },
    "action": action,
    "authorization": {
        "decision": "allow",
        "policy": "mail-policy@42",
    },
    "approval": {
        "approver": "user:bob",
        "action_digest": digest(action),
    },
    "outcome": {
        "status": "success",
        "provider_message_id": "msg-9918",
        "actual_recipient_count": 1,
    },
    "outcome_accountability": {
        "business_owner": "team:project-office",
        "incident_owner": "team:security-response",
    },
}

required = {
    "initiator", "subject", "actor", "operator", "delegation",
    "action", "authorization", "approval", "outcome",
    "outcome_accountability",
}

for name, event in {
    "user_only": user_only,
    "agent_only": agent_only,
    "dual_subject_actor": dual_subject_actor,
}.items():
    missing = sorted(required - event.keys())
    approval_matches = (
        event.get("approval", {}).get("action_digest")
        == digest(event["action"])
    )
    print(name, "missing=", missing, "approval_matches=", approval_matches)

預期輸出：

user_only missing= ['actor', 'approval', 'authorization', 'delegation', 'operator', 'outcome_accountability'] approval_matches= False
agent_only missing= ['approval', 'authorization', 'delegation', 'initiator', 'operator', 'outcome_accountability', 'subject'] approval_matches= False
dual_subject_actor missing= [] approval_matches= True

這個測試證明的不是 JSON 越長越安全，而是 investigation question 需要對應欄位：只記 User 無法找出 executor，只記 Agent 無法證明 delegation，只有 approval ID 也無法證明核准內容與執行內容相同。

此 PoC 還不是 production evidence system。正式環境仍須補上可信時間來源、append-only 或 tamper-evident storage、敏感資料遮罩、retention、schema version、credential verification，以及 decision / approval 的完整性保護。完整的 evidence 設計會在 Day 26、27 再深入。

今天得到什麼

• 「代表使用者」不會讓 Agent 身分消失；subject 與 actor 必須同時可驗證。
• Initiator、subject、actor、approver、operator 與 outcome accountability 是不同角色，不能壓成單一 user_id。
• User intent、結構化 Action、policy decision、approval、Tool request 與 Resource outcome 必須以共同識別碼串成 accountability chain。
• Token claims 能攜帶 delegation identity，但不能替組織決定全部責任，更不能取代 outcome evidence。
• 最好的事故紀錄不是先找一個人背鍋，而是能指出每個角色在何處作了決定、哪一道控制失效。

下一篇

今天我們把一次 Agent Action 裡的責任角色拆開了，但還沒有系統性盤點：攻擊者能從哪裡進來、哪些資產會受影響、authority 又會跨過哪些 trust boundary。

下一篇 Day 5，我們會替一個會自主選 Tool、組參數並執行多步計畫的 Agent 畫 Threat Model，讓這條 accountability chain 變成可以逐點檢查的安全模型。

參考資料

• IETF RFC 8693 — OAuth 2.0 Token Exchange
• IETF RFC 7519 — JSON Web Token
• W3C Recommendation — PROV-O: The PROV Ontology
• NIST AI 100-1 — Artificial Intelligence Risk Management Framework 1.0
• NIST SP 800-53 Rev. 5 — Security and Privacy Controls for Information Systems and Organizations
• OpenTelemetry Specification — Logs