Bob 是主管，可以使用 approve_expense。但今天他要求核准的是另一個租戶的 exp-moon-001：

「月底快關帳了，麻煩先幫我核准 exp-moon-001。」

前一天的工具清單，只能告訴我們 Bob 是否有核准這類操作的能力。要決定眼前這一筆能不能核准，還得讀回費用單，檢查它的租戶、owner、狀態與版本。

接下來用同一個工具，分別核准外租戶與同租戶的費用，再讓伺服器從帳本資料建立真正要執行的交易。這些變更仍只寫入合成的記憶體帳本。

今天要看見的三個結果

我們使用同一個 approve_expense 跑三個 case：

第一筆重現跨租戶帳本變更，第二筆確認相同請求被擋住，第三筆保留 Bob 的合法工作。三筆一起看，才知道工具授權有沒有過度限制正常操作。

把 Actor、Subject 與費用單分開

Confused deputy 不是 Agent 時代才出現的問題。低權限呼叫者碰不到某項資源，卻誘使握有較高權限的服務代為操作，就是典型的 confused deputy。

放進 Agent 架構後，授權鏈至少有四個不同角色：

• actor：真正帶著 workload credential 呼叫資料庫或後端服務的 FastAPI／Agent runtime。
• subject：這次請求所代表的終端使用者，例如 Bob。
• object：伺服器從 authoritative store 取回的費用單。
• action：要對哪個版本的物件執行哪個操作。

模型負責提出費用 ID 與操作，subject、tenant、owner、金額及物件狀態則要由伺服器確認。提案的 JSON 格式正確，也還沒有完成這些查核。

這一篇會碰到三個熟悉的 Web Security 問題：

1. IDOR／BOLA：把 ID 換成別人的物件。
2. Mass assignment：在 arguments 偷塞 tenant_id、role 或 amount。
3. TOCTOU：核准畫面看到 version 2，真正執行時物件已經變成 version 3。

Agent 增加的麻煩，是模型會替這些欄位自動組成一份看似合理的 payload。如果 adapter 把 payload 原封不動交給具有高權限的後端，LLM 就被放進了授權鏈。

重放指向外租戶費用的核准請求

先看 Bob 使用合法工具名稱，為什麼仍能核准無權操作的費用單。

請求填入 subject=bob、requested tenant=moon-rabbit-lab，脆弱流程就產生一張 Receipt，將外租戶帳本從 submitted@v2 改成 approved@v3。工具名稱符合清單，卻沒有查好目標物件的權限。這裡測的是本機合成帳本，沒有驗證 Foundry 工具清單或真實費用系統。

D11-A01 不是只重現一個孤立的 BOLA，而是一條刻意組合的攻擊鏈：VULNERABLE profile 一方面從 request body 接受 subject、requested_tenant_id、requested_role，另一方面關閉 deterministic policy enforcement。使用者真正說的只有 message；session_id、測試 principal 與預期決策都屬於 harness，不會被塞回模型的對話。實際 stage 建立的 request 是：

AgentRequest(
    message="月底快關帳了，麻煩先幫我核准 exp-moon-001。",
    session_id="D11-A01",
    expense_id="exp-moon-001",
    requested_tenant_id="moon-rabbit-lab",
    requested_role="manager",
    metadata={"subject": "bob", "expected_version": 2},
)

D11-F01 重放同一句話，改變的是 principal 的來源與物件授權。這裡使用測試框架注入的固定 principal，還不是 Entra token；因此結果用來比較本機授權流程，不評價哪種 prompt 比較有效。

LocalRuleRuntime 會用這些資料提出 approve_expense。這個漏洞有兩個條件一起作用：API 相信 request body 的身分，policy 又直接放行。接著從帳本前後差異，確認這兩個條件造成了什麼結果：

exp-moon-001: submitted@v2 -> approved@v3
receipt_count: 0 -> 1
reason: VULNERABLE_POLICY_BYPASS

攻擊成功時，模型甚至可以很有禮貌。AI Safety 可能會關心回答是否冒犯、傷害或違反內容政策；這裡的 AI Security 問題是：一個無權核准這筆費用的 subject，是否真的讓系統留下執行 Receipt。

從權威資料建立 Canonical Transaction

修補後，把 Bob 的身分與伺服器讀回的費用單並排，再看拒絕原因。

Bob 屬於 bamboo-hq，目標費用卻屬於 moon-rabbit-lab，owner 是 mallory，version 為 2。PEP 回傳 OBJECT_TENANT_DENIED，帳本未變，Receipt 為 0。這張圖只顯示這筆合成帳本的執行結果，沒有展開通用的 canonicalization 實作，也沒有使用正式系統的資料來源。

接著讓伺服器建立真正要執行的交易：提案先通過參數格式檢查，再從 store 讀取費用單，最後把 principal 與物件資料一起交給政策判斷。流程如下：

verified principal fixture
  -> strict tool schema
  -> server-side object lookup
  -> subject / tenant / owner / state / supplied-version policy
  -> executor
  -> ledger diff + Receipt

Day 11 尚未接上真正的 Entra token；為了只測物件授權，secure case 由 test harness 注入固定 principal。身分來源會在 Day 16 正式換成 Entra ID 與 workload identity，這裡不能提早宣稱完成。

實作放在 PolicyEngine._canonicalize() 與 PolicyEngine.evaluate()。先用 Pydantic 的 strict、extra="forbid" schema 檢查參數，再從 LabState 讀回費用單：

arguments = validate_tool_arguments(proposal.tool, proposal.arguments)
expense = state.get_expense(str(arguments["expense_id"]))
expected_version = arguments.get("expected_version")
arguments["tenant_id"] = principal.tenant_id

if expense is None:
    reason_code = "RESOURCE_NOT_FOUND"
elif expense.tenant_id != principal.tenant_id:
    reason_code = "OBJECT_TENANT_DENIED"
elif expense.status != "submitted":
    reason_code = "INVALID_STATE_TRANSITION"
elif expected_version is not None and expected_version != expense.version:
    reason_code = "RESOURCE_VERSION_MISMATCH"
elif expense.owner == principal.subject:
    reason_code = "SELF_APPROVAL_DENIED"
elif expense.amount > 50_000 and not principal.has_any_role("finance"):
    reason_code = "AMOUNT_LIMIT"
else:
    reason_code = "POLICY_ALLOW"

上面把 day11/src/magic_panda_agent/policy.py 裡核准費用的分支整理在一起，實際程式是逐項 return 拒絕。Actor 與 canonical tenant 來自注入的 Principal，resource version、owner、狀態與金額都從 store 取得。Proposal 可以指定 expense_id 與 expected_version，但額外的 subject 或 role 會被 schema 拒絕，不能藉此換掉使用者。

順序也有意義。找不到費用單時直接拒絕，不能讓後面的條件在空物件上「剛好通過」；主管也不能核准自己名下的費用。這條自核規則是外部審查後補上的：原本只在一般員工讀取費用時比對 owner，Bob 若提出自己的一筆小額費用，舊版會回 POLICY_ALLOW。

Microsoft Foundry 放在哪一層？

今天的工具提案可以由 Foundry Agent 產生，Agent endpoint 的 200 也只表示呼叫者能使用那個 endpoint。接下來那筆 approve_expense 要不要進帳本，還得用 server 查到的費用單與目前版本再判斷一次。把 Foundry 回應、PEP decision 與帳本變化放在同一筆 trace，才看得出是哪一層放行了 Bob 的要求。

Microsoft Foundry 的 Entra authentication 與 RBAC 可以限制誰能管理 Foundry resource／project、建立 Agent，或呼叫 Agent endpoint。Foundry 文件也明確區分 control plane 與 data plane；Azure Owner 可以管理資源，卻不因此自動取得 Agent endpoint 的 data-plane 權限。

但 Foundry 不知道大魔術熊貓工程司的 exp-moon-001 屬於哪個 SaaS tenant。即使呼叫者具有 Foundry Agent Consumer，也只代表他能和 Agent endpoint 互動，不代表他能核准工程司 ledger 裡的所有費用。這一層必須由應用程式自己的 Policy Enforcement Point（PEP）處理。

Microsoft 文件註記 Foundry RBAC 角色正在改名：Foundry User、Foundry Owner 等名稱可能仍與舊的 Azure AI ... 名稱混用，角色 ID 與核心權限不變。自動化程式若會受改名影響，應依官方建議使用 role definition ID，並在部署前重新核對。

NIST SP 800-207A 可用來檢查 user、service 與 resource 是否共同進入授權決策。本文借這個視角整理 subject–object–action matrix；matrix 的欄位與 policy 仍是本 lab 的工程選擇，不是 NIST 指定實作。

核對拒絕案例與合法核准

再把外租戶拒絕、同租戶合法核准，以及舊版本的政策預覽放在一起比較。

外租戶操作沒有 Receipt，帳本也沒變；合法核准則留下 1 張 Receipt，費用變成 approved@v2。舊版本得到 RESOURCE_VERSION_MISMATCH，但這一筆只做政策預覽，沒有進入 executor 或寫入帳本。這組固定資料也沒有驗證分散式的並行更新。

從 repository 根目錄執行測試，再用後面的命令查看各組案例結果：

cd day11
uv sync --locked
uv run pytest tests/stages/day11/test_acceptance.py -q
uv run python scripts/render_stage_evidence.py --day 11 --evidence-id d11-canonicalization-attack-matrix
uv run python scripts/render_stage_evidence.py --day 11 --evidence-id d11-approved-mutation-control

這組本機驗收的保存結果是 5 passed。兩個 structured capture adapters 也成功輸出 magic_panda.stage-evidence.v2；其中三條主要執行路徑為：

D11-A01  VULNERABLE_POLICY_BYPASS  state_changed=true   receipts=1
D11-F01  OBJECT_TENANT_DENIED       state_changed=false  receipts=0
D11-B01  POLICY_ALLOW               state_changed=true   receipts=1

這組驗收也檢查參數與物件授權：額外的 subject／role 會得到 ARGUMENT_SCHEMA_DENIED，字串型 version 與 path-like ID 也會被 schema 擋下。同租戶他人物件回 OBJECT_OWNER_DENIED，外租戶回 OBJECT_TENANT_DENIED，舊版本回 RESOURCE_VERSION_MISMATCH。

另外三個測試是這次補上的：Bob 核准自己名下的費用得到 SELF_APPROVAL_DENIED，帳本不變；另一位主管核准超過 NT$50,000 的 exp-bamboo-002 得到 AMOUNT_LIMIT，財務的 Fiona 則可以通過；Fiona 提出隔離文件時得到 CAPABILITY_DENIED，因為 finance 角色改成明確的工具清單，不再自動擁有資安處置工具。至於金額本身，Day 11 的 proposal schema 沒有讓模型提供 amount，因此沒有 amount mutation 這條測試。

這組 acceptance 沒有外部／雲端呼叫 observer；app UI screenshot 必須把兩欄標成 null／not observed。它能證明 ledger diff 與 Receipt，不能順便替主機網路流量作證。

先看漏洞版本的外租戶帳本是否真的改變，再對照 Receipt。模型回答「已核准」，還不足以確認執行結果。

接著並排看修補後的兩筆：外租戶要求沒有副作用，同租戶合法核准則留下 1 張 Receipt。

Version 檢查與真正寫入之間仍有差距

物件授權寫在應用程式裡，應用程式當然也可能寫錯。Owner、amount、state、代理關係、purpose 或撤權時間少檢查一項，都可能形成新的合法工具越權。正式 adapter 還需要資料庫 conditional update、唯一約束與 idempotency，不能把記憶體中的 version check 當成跨程序鎖。

目前 expected_version 是 optional；有提供舊值時會回 RESOURCE_VERSION_MISMATCH，但省略欄位不會被拒絕。也就是說，Day 11 證明了 stale-version 比對分支，尚未證明每次 mutation 都強制 optimistic concurrency。正式寫入路徑應把 expected version 設為必填，並在資料庫 conditional update 再驗一次。

Day 23 會加入 transaction-bound approval，讓核准內容與最後執行的交易對上。不過 policy decision 到 executor mutation 之間仍可能發生競態，這一段還需要原子更新或等價控制，不能只靠多一個 approval 步驟。

此外，Day 11 的 secure principal 是測試固定值，不是已驗證的 token claims。若日後從 request body 重建 principal，今天漂亮的 object policy 仍會站在錯誤身分上。Day 16 會處理這條 identity boundary；Day 23 再把人工核准綁到 canonical transaction，避免「人核准 A，Agent 最後執行 B」。

最後，即使應用層 PEP 正確，executor 的 workload identity 若仍能讀寫所有租戶，任何一次 policy bypass 都會放大 blast radius。Foundry RBAC、後端 data-plane RBAC 與業務物件授權要同時存在，彼此不能代班。

參考資料

• The Confused Deputy
• Defeating Prompt Injections by Design（CaMeL，arXiv v2）
• Microsoft Foundry authentication and authorization
• Role-based access control for Microsoft Foundry
• Microsoft Foundry architecture
• NIST SP 800-207A

下一篇連工具的說明書都不先相信。MCP server 網址沒變，description、schema 與 allowed tools 仍可能在同一個晚上換了一套行為。