Core Question

要重建 Agent 決策與 side effect，哪些 evidence 必須跨 identity、delegation、policy、approval 與 Tool 執行被關聯？

今天的問題

客服 Agent 受 Alice 委託查詢訂單，必要時建立補寄單並寄信。事件發生後，團隊只找到一筆 prompt="處理訂單 4821" 和一筆 service-account called mail.send: success。這兩筆紀錄都可能是真的，卻回答不了：是哪個 Agent instance 選了收件者？Alice 的 delegation 是否包含寄信？PDP 用哪一版 policy？Resource 是否真的改變？

為什麼這不是傳統 IAM 問題

傳統 API log 通常以一次 request 為單位；Agent 卻把自然語言目標拆成多步、由模型動態選 Tool，且 Tool output 會改變下一步。Prompt 是規劃輸入，不是 Action；反過來，Action log 也沒有 intent、delegation 或 policy 原因。拿掉 Agent 後，這個「規劃迴圈造成的 authority chain」便不成立。

Threat / Failure Scenario

Naive 系統只記 prompt、最後 API 呼叫和 HTTP status。模型從 CRM 備註讀到外部指令，將原本的內部收件者換成外部地址；API 成功後，稽核只能看到 Alice 曾經說過「處理訂單」，無法確認參數何時被改、誰批准、哪一個 actor 執行。

核心概念

Audit Log 不等於完整 Evidence

Audit log 是事件紀錄；evidence 是能把事件關聯、驗證並重建因果的資料集合。最低限度應有同一 trace_id/task_id 下的七類事件：request（發起者與受控 intent 摘要）、delegation（subject/actor/scope/expiry）、planning（Agent instance、版本與 structured Action）、decision（PDP、policy version、constraints）、approval（核准者與 Action digest）、execution（PEP 實際送出的 canonical Action）、outcome（Tool 回應與 Resource side effect）。

Prompt 可保留，但應是受控、分級、可遮罩的 context，不應把 chain-of-thought 當稽核必要資料。敏感 prompt 應以摘要、hash、retention policy 和存取控制處理；Action parameters 若含個資，也需分欄位保護，而不是為了「完整」永久保存所有原文。

OpenTelemetry 的 Context/SpanContext 可跨 API 邊界傳遞 execution-scoped context，適合做 correlation；但 trace propagation 本身不代表 authorization，也不應被當成不可竄改證明。OpenTelemetry Context 、OpenTelemetry Tracing API

Architecture Pattern

Naive / Unsafe Design

User prompt -> Agent -> Tool
log: prompt + service-account + HTTP 200

Recommended Design

Trust boundary 位於 Agent runtime 與 Gateway 之間：Agent 可提出 Action，但不能寫入 decision 或 outcome。Gateway 是 PEP，PDP 必須同時看到 subject、actor、task、Action、resource 與 policy version。Identity flow 是 User Identity + Agent Identity + Delegation Context → PDP → constrained Tool call；Evidence plane 則以 correlation ID 關聯每個 lifecycle event。

Authorization Decision Point

決策事件至少包含 decision_id、trace_id、subject、actor、delegation id、canonical Action digest、resource、policy id/version、decision、constraints、expiry。它描述「為何當時允許」，但本日的重點仍是可調查性，不宣稱 log 已具備不可否認性；那是 Day 27 的問題。

小型 PoC

import json

events = []
def emit(kind, **fields):
    events.append({"kind": kind, "trace_id": "tr-26", **fields})

emit("request", subject="alice", task="t-26", intent="處理訂單4821")
emit("delegation", actor="agent:ops/i-7", scope=["order.read", "reship.create"])
action = {"op": "reship.create", "order": "4821", "reason": "warehouse_delay"}
emit("decision", action=action, policy_version="p-3", decision="allow")
emit("execution", action=action, pep="gateway-1")
emit("outcome", resource="order:4821", side_effect="reship-created")

required = {"request", "delegation", "decision", "execution", "outcome"}
assert required <= {e["kind"] for e in events}
assert events[2]["action"] == events[3]["action"]
print(json.dumps(events, ensure_ascii=False, indent=2))

執行結果應印出五個相同 trace 的事件，並通過 Action 比對。PoC 證明的是「Prompt、decision、實際 Action、side effect 可被關聯」；它沒有證明儲存體抗竄改，也沒有保存 chain-of-thought。

今天得到什麼

• Prompt 是 context，不是實際執行證據；Action、decision 與 outcome 必須獨立記錄。
• Audit log 是事件，Evidence 是可關聯、可重建的事件集合。
• subject、actor、delegation、task 與 policy version 不應被 service account 壓平。
• OpenTelemetry 能提供 correlation，不會自動提供授權或不可竄改性。

下一篇

今天解決「要記哪些事件」；下一篇進一步問：如何證明這份 allow 在當時真的綁定了那個 Action，而且執行前沒有被換參數？

參考資料

• OpenTelemetry Context specification
• NIST SP 800-53 Rev. 5, AU-3