高風險操作可以先停下來，讓人確認。但要讓核准有效，系統還得確認：Bob 看見、同意與 executor 最後執行的，是不是同一筆交易？

今天沿用工程司的費用核准，把 actor、tenant、resource、參數與版本綁成 canonical action。接著檢查換單、過期、重放，以及兩個請求同時使用同一張核准的情況。

這份 lab 沒有實作 approval UI。它測的是 UI 背後需要的本機協定：核准者是否合格、交易有沒有改變，以及成功操作能否只留下同一張 Receipt。

Canonical Action、Action Hash 與 Nonce

• HITL（Human-in-the-loop）：在高風險操作前加入人工判斷；人必須看到並核准完整交易內容。
• Canonical action：把 actor、subject、tenant、工具、資源、參數與版本轉成唯一表示，避免 UI 與 executor 各說各話。
• Action hash：canonical action 的雜湊摘要；任何欄位變更都應得到不同摘要。
• Nonce：只能使用一次的隨機識別值，用來阻止同一張 approval 重放。
• TOCTOU：檢查（time of check）和真正使用（time of use）之間狀態改變。最終狀態重驗、approval consume 與 mutation 必須在同一個 lock／transaction 內完成。

核准完成後，交易還可能在哪裡改變？

一個只保存 approved=true 的流程，會留下幾個明顯缺口：

• UI 顯示 action A，approval 後把 resource 或參數換成 action B；
• 同一張 approval 重放兩次，工具留下兩張 Receipt；
• action 核准後，resource 已從 version 4 改成 version 5；
• Alice 自己核准自己的高風險要求；
• moon-rabbit-lab 的 approver 核准 bamboo-hq 交易；
• Bob 核准後被撤權，舊 approval 仍永久有效；
• Agent 只把一段摘要給人看，真正敏感的 destination、tenant 或金額藏在參數裡。

這些問題發生在 approval UI、service 與 executor 之間。只要各元件對交易內容的理解不同，即使模型輸出沒有改變，也可能執行到未經核准的操作。

固定業務要求，逐項修改交易與核准資料

核准後換掉 resource 或 proposal source，再看原本的核准還能不能使用。

兩種變更都得到 APPROVAL_ACTION_MISMATCH，new_receipt_count=0、new_side_effect_count=0。這些結果只涵蓋列出的本機換單案例，使用合成 approver 與 token，沒有驗證 Entra Conditional Access。

今天固定一筆需要人工核准的合成費用。費用屬於 Alice，Fiona 以 finance 身分建立 canonical action，Bob 再以 manager 身分完成 step-up 核准。Owner、執行者與核准者分開，後面才看得出誰能替哪筆交易做決定。

這一輪不需要替攻擊者加工 prompt。模型看到的業務訊息始終只是：

請幫我核准 exp-bamboo-001。

接下來竄改的是 proposal 之後的 canonical transaction、approval token 與 server state。Case ID、token fault 與預期 reason 都留在 test oracle，不會倒灌回對話。

攻擊矩陣逐項改掉交易證據：

兩種重送會先遇到不同檢查。D23-A01 沒有執行工具，直接驗證 nonce 重放；D23-A02 已把費用改成 approved@version=2，因此重送先得到 INVALID_STATE_TRANSITION。真正的同 token 併發，則另外用 32 次 thread race 驗證。

矩陣裡的 D23-A10 擋的是「提出操作的人自己核准」。還有一種情況它沒涵蓋：Fiona 提出核准 Bob 名下的 exp-bamboo-002，再找 Bob 本人簽核准。外部審查後補上了這條檢查：核准者不能是費用 owner，簽發時回 APPROVER_RESOURCE_OWNER_DENIED；即使 token 已簽出，使用當下若 owner 變成核准者，也會用同一個原因拒絕。

從 Action 建立核准，再於執行前重驗

步驟一、建立 canonical action

先讀程式實際輸出的 canonical action，確認核准綁定哪些欄位。

畫面列出 actor、tenant_id、tool、resource_id／version、expected_version、proposal_source 與 action_hash，沒有顯示 amount、destination 或 policy version。這裡只能核對輸出的交易資料，不能確認正式系統的來源管理、核准畫面是否完整，或 UI 防網路釣魚措施。

核准要綁定伺服器重新建立的 action，不能只對著模型摘要按同意：

from typing import Any

from pydantic import BaseModel, Field

from magic_panda_agent.models import ToolName, sha256_json


class CanonicalAction(BaseModel):
    tool: ToolName
    actor: str
    tenant_id: str
    proposal_source: str = "model"
    resource_id: str | None = None
    resource_version: int | None = None
    arguments: dict[str, Any] = Field(default_factory=dict)
    risk: str = "low"

    @property
    def action_hash(self) -> str:
        return sha256_json(self)

sha256_json() 用固定排序與 separators 建立穩定表示。Tool、actor、tenant、resource、version、source、arguments 或 risk 任一改變，action hash 就應改變，讓核准內容能對回最後執行的交易。

步驟二、核准 claims 不只放 yes

再看核准者、時效與 nonce 摘要，確認它們是否綁定同一筆 action。

action_hash_matches=true，畫面也保留核准者的 subject／tenant／roles、authentication_context、approval_epoch、expires_in_future，以及 nonce 是否存在和長度。這些摘要足以核對綁定，不需要公開 token、hash 或 nonce 原值。合成簽章仍不能代替企業的 step-up 認證與金鑰管理。

本機使用的合成 approval envelope 包含：

{
  "action_hash": "<sha256>",
  "approver_subject": "bob",
  "approver_tenant_id": "bamboo-hq",
  "approver_roles": ["manager"],
  "authentication_context": "synthetic-step-up",
  "nonce": "<one-time-value>",
  "approval_epoch": 1,
  "expires_at": "<short-lived UTC timestamp>"
}

resource_version 沒有重複放進 claims；它已在 canonical action 裡，連同 tool、actor、tenant、proposal source、resource、arguments 與 risk 一起被 action_hash 涵蓋。approval_epoch 則綁定目前 replay-store 世代；local lab reset 會先推進 epoch，舊 token 即使 signature 與 expiry 都還有效，也會得到 APPROVAL_EPOCH_MISMATCH。Lab 使用 ephemeral signing key 與 thread-safe 記憶體 replay store，只為了重現 protocol。它不是 production signing service，也沒有跨 process durability。正式系統還要記錄 key version、authority version 與 approver 權限變更。

步驟三、最終狀態重驗、consume 與 mutation 放在同一個臨界區

接著讓多個請求同時進來，確認最終檢查、nonce 消耗、帳本更新與 Receipt 保存都在同一個臨界區完成。

32 次嘗試只呼叫 1 次 consume，確實更新了帳本，state 留下 1 張 Receipt 與 1 次副作用；另外 31 次重用既有 Receipt。這組結果只涵蓋單一 process、記憶體內的一把 lock，以及相同 action 的重複呼叫，沒有驗證跨 process、資料庫 rollback 或分散式 exactly-once。

正確資料流如下：

ToolProposal
  → PEP 建立 CanonicalAction
  → REQUIRE_APPROVAL
  → UI 顯示完整交易與差異
  → approver step-up + separation of duty
  → 簽出短效、一次性 approval
  → executor 取得 resource execution lock
  → 先查同一 canonical action 是否已有 Receipt；有就回傳既有 Receipt
  → 以既有 CanonicalAction 對 current resource 做 final admission，重驗 kill switch / revocation / status / version / tenant
  → 驗 signature / expiry / authority / epoch / nonce
  → 在同一臨界區 consume nonce、mutation、Receipt / idempotency record

Approval UI 尚未實作。正式介面需要呈現足以辨識交易的 destination、resource、金額與資料範圍，再讓 approver 確認；若只顯示工具名稱，就無法判斷接下來執行的內容。

這組測試用 ThreadPoolExecutor 同時送出 32 次 execute_with_approval()，每次使用同一 token 與同一 action。第一個 caller 完成最終檢查、consume、帳本變更與 Receipt；其餘 31 個取得同一把 lock 後，找到已完成的 Receipt，就直接回傳它。

所以結果要同時符合 consume_call_count=1、approval_valid_consume_count=1、duplicate_receipt_reuse_count=31、unique_returned_receipt_count=1。帳本只從 submitted@version=1 變成 approved@version=2，state 也只留下 1 張 Receipt 與 1 次副作用。結束後再直接 consume 同一 token，仍會得到 APPROVAL_REPLAY。

這裡的順序值得留意：executor 先找同一個 action 是否已有 Receipt，找到就直接回傳，還沒驗 token。走 service 的正常路徑時，PEP 會先用 validate() 檢查 token，所以壞掉或過期的核准到不了這一步；但如果有人跳過 service 直接呼叫 executor，重複的請求就能拿回既有的 Receipt。它不會多做一次副作用，卻會把「重送」顯示成成功。正式系統若把 executor 開放給其他元件呼叫，應該先驗 token，再決定是否沿用舊結果。

另外一個較小的測試只呼叫 ApprovalService.consume()，結果是 1 個 APPROVAL_VALID 與 31 個 APPROVAL_REPLAY。它只檢查 nonce，前面的完整測試才包含帳本變更與 Receipt。兩者都限於同一個 Python process 與記憶體 lock，沒有涵蓋跨 process、資料庫 rollback 或外部 API 的復原。

另一個 race 用來檢查物件狀態變動：A、B 都先在 version 1 通過 PEP，B 執行後將物件推到 version 2，再讓 A 執行。Final admission 應回 RESOURCE_VERSION_MISMATCH，而且不能先消耗 A 的 approval。這樣才能補上政策檢查與真正使用之間的時間差。

Microsoft Foundry 與 MCP approval 能做哪一段

今天 Bob 核准的是一筆有版本、金額與收件目的地的交易，不只是畫面上的「允許工具」。若把工具接進 Foundry MCP，mcp_approval_request 可以讓流程暫停；工程司仍要在核准前顯示 canonical action，恢復執行時再比對同一組欄位。否則 Agent 送出另一筆 arguments，平台上的 approval 事件也不能證明這筆帳本變更經過核准。

Foundry MCP tool 可設定 require_approval。官方 MCP 驗證文件列出 always、never 與逐工具清單；需要核准時，response 會出現 mcp_approval_request，應用程式核准後再送出下一個 response 繼續。

這項能力能建立 pause／resume 的 runtime 介入點，但不會自動替大魔術熊貓工程司定義：

• Bob 是否有核准該 tenant 與金額的業務權限；
• UI 是否顯示 canonical action；
• approval 是否綁定 resource version 與 destination；
• nonce 是否跨 worker 原子消耗；
• executor 是否只接受同一筆 action。

Foundry toolbox 文件指出，MCP proxy 不會單憑 require_approval 阻擋 tools/call，執行核准檢查的是 agent runtime。因此還要追到實際呼叫入口，確認所有路徑都會經過 approval enforcement。

這份 lab 沒有建立 Foundry MCP connection，也沒有取得 mcp_approval_request；這裡先對照官方流程與本機核准協定的分工。

成功只能留下同一張 Receipt

最後將 canonical action 的 hash 對回 Receipt，再看帳本版本是否只前進一次。

receipt_matches_action=true，只留下 1 張 Receipt，帳本變成 approved@version=2。這筆紀錄與核准交易相符，但還不能證明跨服務的 exactly-once，也無法判斷核准者是否受到社交工程影響。

從 day23/ 執行：

uv sync --frozen --extra dev
uv run pytest tests/stages/day23/test_acceptance.py -q

驗收要看四組資料一起對得上：

1. approval claims 的 action_hash；
2. executor 收到的 canonical action digest；
3. Receipt 保存的 action digest；
4. ledger 的 resource ID、status 與 version change。

先看拒絕矩陣：每筆新增 Receipt 都應是 0，合法的 D23-B01 則是 1。再看 32-thread 測試，consume、mutation 與保存 Receipt 都只做一次，其餘 31 次重用結果。Reset 後的舊 token 應得到 APPROVAL_EPOCH_MISMATCH。

兩個 version-1 action 交錯執行時，較晚的一筆也必須在 mutation 與 consume 前被拒絕。新增的第 11 個測試則確認費用 owner 不能替自己的費用簽核准。當日驗收記錄為 11 passed，未涵蓋 Receipt store failure、跨 process replay、rollback 與 retry。

PYTHONPATH=src:. uv run python scripts/render_stage_evidence.py --day 23 --evidence-id d23-approval-negative-matrix

JSON 保存 D23-A01～D23-A11 的拒絕原因，每筆 new_receipt_count=0、new_side_effect_count=0。其中 D23-A02 還保留先前成功交易的 Receipt=1，所以要分清楚「原本已存在」與「這次新增」。畫面只顯示案例、原因與次數，不輸出 token、signature 或完整 hash。

最後對照成功交易：

PYTHONPATH=src:. uv run python scripts/render_stage_evidence.py --day 23 --evidence-id d23-approved-action-control

來源 JSON 應顯示 Fiona 對 exp-bamboo-001@version=1 的 canonical action、receipt_matches_action=true、一張 side-effect Receipt，以及 ledger 變成 approved@version=2；app UI screenshot 會保留 D23-B01、POLICY_ALLOW、Receipt=1、side-effect=1 與 結論適用範圍。這仍是 synthetic step-up，不是 Entra Conditional Access 實測。

技術綁定之外，仍需設計人工審查

NIST AI RMF 1.0 是自願採用（voluntary）的框架；GOVERN 3.2 描述人機配置與 oversight 角色責任，MAP 3.5 則把 human-oversight process 的定義、評估與紀錄接回治理政策。本 repo 才把這組 outcome 轉成 approver identity、separation of duty、action binding、expiry、nonce 與 Receipt；這些欄位是大魔術熊貓工程司的 protocol，不是 NIST 規定的 token schema。

Transaction binding 仍擋不住社交工程、approver fatigue、內部人濫權與 UI 欺騙。Signing key 或 nonce store 被控制時，完整 claims 也只會替錯誤交易蓋出很工整的章。正式環境還要做風險分級、速率限制、多人核准、step-up authentication、撤銷、durable replay store 與定期抽查。

明天開始自動化紅隊。PyRIT 會負責編排固定攻擊，但 scorer 不看 Agent 最後講得多有禮貌，而是回來查 Receipt、跨租戶參考碼與 in-memory outbox。

官方參考資料

• Microsoft Learn, Set up MCP server authentication: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication
• Microsoft Learn, Create and manage a toolbox in Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/toolbox
• Microsoft Learn, Connect to Model Context Protocol servers: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/tools/model-context-protocol
• Microsoft Learn, Guardrails and controls overview in Microsoft Foundry: https://learn.microsoft.com/en-us/azure/foundry/guardrails/guardrails-overview
• Microsoft Learn, Microsoft Foundry portal general availability overview: https://learn.microsoft.com/en-us/azure/foundry/concepts/general-availability
• NIST, AI RMF Core: https://airc.nist.gov/airmf-resources/airmf/5-sec-core/