昨天的 layered guardrails 最後仍會遇到一個合理要求：高風險工具先停下來，等人確認再執行。這個方向沒錯，但 REQUIRE_APPROVAL 只代表流程需要一個人，還沒說清楚那個人看了什麼、同意什麼，以及同意之後程式有沒有偷偷換貨。

大魔術熊貓工程司不缺「同意」按鈕，缺的是能證明 Bob 同意的正是 exp-bamboo-001@version=1，而不是畫面上顯示一筆，送到 executor 時變成另一筆費用。人類按下同意，也要先確認按的是哪一筆；不然 HITL 只是把責任轉交給一顆按鈕。

先備名詞：核准的是完整交易，不是一個模糊的「好」

• 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 內完成。

Threat：approval 與 action 中間有一條時間縫

一個只保存 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 對交易身分的理解不一致。

Attack：不改 prompt，直接改 canonical transaction

畫面判讀目標： 確認已綁定的 approval 會拒絕核准後變更 resource 或 proposal source 的嘗試。

綁定完整交易後，核准後換 action 只會得到 mismatch。 可觀察狀態：兩種變更都得到 APPROVAL_ACTION_MISMATCH，new_receipt_count=0、new_side_effect_count=0。 Claim boundary：只驗 synthetic approver/token 與列出的本機 tamper cases，不是 Entra Conditional Access。

今天固定一筆 stage-local synthetic action：Alice 擁有原始費用，fixture 將金額提高到需要人工介入的門檻；Fiona 以 finance 身分建立 canonical action，Bob 以 manager 身分完成 step-up 核准。owner、執行者與 approver 是三個不同 principal。

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

請幫我核准 exp-bamboo-001。

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

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

D23-A01 與 D23-A02 要分開讀。前者在沒有執行工具的 fixture 中證明 nonce 重放會被拒絕；後者先成功把費用改成 approved@version=2，重送時先撞上 INVALID_STATE_TRANSITION。真正的同 token 競爭另由 32 次 thread race 驗證，不能拿這筆循序 replay 代替。

Fix：把人、交易與時間一起綁定

步驟一、建立 canonical action

畫面判讀目標： 核對 approval evidence 實際輸出的 canonical action 欄位。

只核對 runtime 實際輸出的 canonical action 欄位。 可觀察狀態：actor、tenant_id、tool、resource_id/version、expected_version、proposal_source 與 action_hash 可讀。 Claim boundary：畫面不含 amount、destination 或 policy version，也不證明 production source ownership、approver 顯示完整性或 UI anti-phishing。

PEP 不簽模型摘要，而是簽 server 重新建立的 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() 使用 canonical JSON；排序與固定 separators 的目的不是讓 JSON 比較漂亮，而是讓同一筆交易得到相同 bytes。Tool、actor、tenant、resource、version、source、arguments 或 risk 只要一項不同，action_hash 就不同。

步驟二、核准 claims 不只放 yes

畫面判讀目標： 讀取 action match、approver、epoch、expiry future 與 nonce presence/length 的 disclosure-safe summary。

核對 approval binding，不必公開 token、hash 或 nonce 原值。 可觀察狀態：action_hash_matches=true；approver subject/tenant/roles、authentication_context、approval_epoch、expires_in_future、nonce_present/length 可讀；raw token/hash/nonce 均未輸出。 Claim boundary：畫面不輸出 raw action hash、nonce 或 token；synthetic signing 不證明企業 step-up auth 或 key custody。

V2 synthetic 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 放在同一個臨界區

畫面判讀目標： 確認單一 process 的最終 admission、nonce consume、ledger mutation 與 Receipt persistence 共用同一個臨界區。

同一個臨界區包住最終重驗、consume、mutation 與唯一 Receipt。可觀察狀態：attempt_count=32、consume_call_count=1、mutation_exercised=true、state_receipt_count=1、state_side_effect_count=1、duplicate_receipt_reuse_count=31。Claim boundary：只證明單一 process、單一 in-memory lock 與同 action 的 idempotent Receipt reuse；不證明跨 process、資料庫 rollback 或 distributed 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

當日 lab 沒有實作 approval UI。正式 UI 可以遮掉不必要的個資，但不能遮到 approver 無法辨認 destination、resource、金額與資料範圍；確認畫面若只寫「Agent 想執行一個工具」，跟在空白支票上蓋章差不多。

這版 acceptance 除了循序 negative matrix，也用 ThreadPoolExecutor 對同一 token 與同一 canonical action 發動 32 次完整 execute_with_approval() 競爭。第一個 caller 完成 final admission、consume、mutation 與 Receipt；另外 31 個 caller 在取得同一把 execution lock 後找到 action-bound Receipt，直接重用它，不再呼叫 approval consume。因此必須同時看到 consume_call_count=1、approval_valid_consume_count=1、duplicate_receipt_reuse_count=31、unique_returned_receipt_count=1，而 state 最後只有一張 Receipt、一個 side effect，resource 只從 submitted@version=1 前進到 approved@version=2。Race 結束後再直接 consume 同一 token，仍得到 APPROVAL_REPLAY。

較低層另有一個只呼叫 ApprovalService.consume() 的單元測試，結果仍是 1 個 APPROVAL_VALID 與 31 個 APPROVAL_REPLAY。那個測試只證明 process-local nonce store，不是本張 UI，也不能取代包含 mutation 與 Receipt 的 transaction race。完整 race 仍只證明同一個 Python process、同一把 in-memory lock 與同 action Receipt reuse；跨 worker、process、region 與 durable store 未驗。Receipt store failure、rollback、transactional outbox 與補償流程仍是 production gaps；外部 API 已發生的效果不能靠 Python object snapshot 倒帶。

另一個 race 會先讓 A、B 兩筆 action 都在 resource@version=1 通過 PEP，先執行 B 使 resource 前進到 version 2，再送出 stale A。final admission 必須回 RESOURCE_VERSION_MISMATCH，而且不能消耗 A 的 approval。這個 regression 專門抓 「policy 當時看對了，executor 後來仍照舊資料做」的 TOCTOU。

Microsoft Foundry 與 MCP approval 能做哪一段

截至 2026-08-03，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 文件還特別說明，toolbox MCP proxy 不會因 require_approval 自己阻擋 tools/call，approval enforcement 是 agent runtime 的責任。這個細節很值得記住：metadata 寫著「要核准」，不等於所有旁路入口都已經上鎖。

本篇沒有建立真實 Foundry MCP connection，也沒有擷取 mcp_approval_request；雲端證據維持 PENDING-CLOUD。

Test：成功只能留下同一張 Receipt

畫面判讀目標： 核對 canonical action hash、receipt_matches_action、唯一 Receipt 計數與 ledger version change。

成功只能留下與核准交易完全相同的一張 Receipt。 可觀察狀態：receipt_matches_action=true、exactly one Receipt、ledger approved@version=2。 Claim boundary：不證明跨服務 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。

Negative matrix 每一筆新 Receipt 都必須是 0；D23-B01 則必須 exactly one。同 token、同 action 的 32-thread transaction race 必須只呼叫 consume 一次、只做一次 mutation 並保存一張 Receipt，其餘 31 次重用既有 Receipt；reset 後的舊 token 必須是 APPROVAL_EPOCH_MISMATCH。兩個 version-1 action 交錯時，後執行的 stale action 必須零 mutation、零新 Receipt，且 approval 尚未消耗。本次 Day 23 acceptance 為 10 passed。Receipt store failure、跨 process replay、rollback 與 retry 仍沒有 acceptance，不能順手寫成「exactly once across production」。

攻擊／before-state UI 的發布契約要求呈現 tamper／replay matrix。正式 app UI screenshot 必須由目前相關原始碼經 repository UI capture pipeline 產生；下列命令只重現對應的 disclosure-safe structured JSON：

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

來源 JSON 應列出 D23-A01 到 D23-A11 的 exact reason code，每筆 new_receipt_count=0、new_side_effect_count=0；D23-A02 另保留先前成功交易的 persisted Receipt=1。app UI screenshot 只呈現 11 個 case ID、reason code、new Receipt／side-effect 總數 0 與 claim boundary；token、signature 與完整 hash 都不輸出。

修補／test UI 只保留成功交易與 exactly-one oracle：

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 與 claim boundary。這仍是 synthetic step-up，不是 Entra Conditional Access 實測。

這些 structured capture 命令只輸出 disclosure-safe JSON，不會直接寫 PNG；正式發布時，本篇 required app UI 圖必須由 repository UI capture pipeline 以 manifest-last 的可回復交易產生。schema 3 manifest 必須以 source-tree SHA-256 與檔案數綁定實際輸入，並由 strict verifier 重算。兩份 structured capture 都保留 FOUNDRY_MCP_APPROVAL_NOT_EXERCISED 與 MICROSOFT_ENTRA_STEP_UP_NOT_EXERCISED，避免 synthetic pause／step-up 被誤認成雲端 MCP approval 或 Conditional Access 實測。

Residual Risk：按了同意，不等於完成 oversight

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。

官方參考資料

以下資料均於 2026-08-03 查閱：

• Microsoft Learn, Set up MCP server authentication: https://learn.microsoft.com/en-us/azure/foundry/agents/how-to/mcp-authentication
• Microsoft Learn, Curate intent-based toolbox in Foundry（Preview）: 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/