昨天把 Prompt Shields 當作 deny-only 訊號加入授權流程。今天再把內容風險、工具覆蓋範圍與 application PEP 放在一起，檢查多個判斷衝突時的優先順序。
同樣看到 Block，原因可能不同：使用者沒有權限、內容政策命中，或工具還沒納入檢查。先把每一層的結果留下來，除錯時才知道該往哪裡找。
這次從 canonical proposal 直接測六筆合成案例。每筆先取得真正的本機 PEP decision，再合併 cassette signals；只有被允許執行的一筆會留下 Receipt。實際 Foundry guardrail assignment 與 intervention trace 尚未驗證。
大魔術熊貓工程司同時會遇到下面幾種決策組合：
mcp-server 的 notify_vendor；PEP 允許，但該 tool enum 不在本機 coverage 集合。這四種情況需要不同的處理方式。內容無害卻越權，要查物件授權；合法讀取因內容政策被擋，要查風險分類與門檻。分開保存結果，才能避免一個 safe 欄位蓋掉真正原因。
先看六筆案例最後由哪一層決定結果，再往下追拒絕或放行的原因。
A01／A02 由 application PEP 決定，A03／A04 分別由 content 與 prompt attack signals 收緊，A05 因本機 coverage 未涵蓋而拒絕，只有 B01 進到 executor。這些 signals 來自本機 cassette，不是 Foundry cloud trace。
這一篇直接測 composition 的不變條件，沒有另外執行 vulnerable composer。下面的案例用來確認 detectors clear 不會放寬 PEP deny，其他訊號也只能在既有授權上增加限制。
Day 22 固定六個 cases：
| Case | PEP | 其他訊號／coverage | 應有結果 |
|---|---|---|---|
D22-A01 Alice 核准 Bob 費用 |
CAPABILITY_DENIED |
無 attack hit | 保留 PEP deny，Receipt=0 |
D22-A02 Bob 操作外租戶物件 |
OBJECT_TENANT_DENIED |
內容無害 | 保留 tenant deny，Receipt=0 |
D22-A03 合法讀取但內容命中 |
allow | content risk | SAFETY_CONTENT_BLOCK |
D22-A04 合法 action 遇攻擊訊號 |
allow | prompt attack | ATTACK_SIGNAL_BLOCK |
D22-A05 source=mcp-server 的 local notify_vendor proposal |
allow | tool enum 不在 coverage | fail closed，Receipt=0 |
D22-B01 Alice 查自己的費用 |
allow | 全部 clear 且 coverage 成立 | read-only Receipt=1 |
D22-A01 與 D22-A02 的文字沒有攻擊關鍵字，仍應被 PEP 拒絕。我們用這兩筆確認：就算 detector 沒看到可疑內容，業務授權還是會檢查。
content 與 attack 都沒有命中時，再確認 PEP 的拒絕是否仍被保留。
D22-A01 的 content=false、attack=false、covered=true，但 base PEP 與 composed reason 仍是 CAPABILITY_DENIED，Receipt 也維持 0。畫面只證明本機 composer 的 post-fix 行為，不評估 Microsoft 分類器品質。
D22-A05 測的是另一個邊界。程式把 GET_EXPENSE、APPROVE_EXPENSE、EXPORT_EXPENSES 放進本機支援集合，再送入集合外、proposal source 為 mcp-server 的 NOTIFY_VENDOR，確認它在 executor 前得到 GUARDRAIL_COVERAGE_UNSUPPORTED。這不是同名工具或 path replay 測試。
換成 PEP 原本允許的操作，看看 content、attack 與 coverage 如何增加限制。
A03 的 content=true 對應 SAFETY_CONTENT_BLOCK，A04 的 attack=true 對應 ATTACK_SIGNAL_BLOCK，A05 的 covered=false 對應 GUARDRAIL_COVERAGE_UNSUPPORTED；三筆 Receipt 都是 0。這張圖只比較本機 booleans 與 outcome，不宣稱 provider 或 integration coverage。
Azure AI Content Safety 的 text analysis 可處理 Hate、Sexual、Self-harm、Violence 與自訂 blocklist。它適合回答「文字是否超過內容政策門檻」，看不懂 bamboo-hq、expense owner、主管限額或 resource version。
Prompt Shields 也是 Azure AI Content Safety 的能力，負責 user prompt attack 與 indirect attack。在 Microsoft Foundry 的 guardrail 裡，這些分類結果會依 control 設定作用在支援的 intervention point。本機程式把 content 與 prompt attack 分別轉成 SecuritySignal，category 也保持分開，避免後續只剩一個模糊的 blocked=true。
Microsoft Foundry 支援四個 Agent intervention points：
user input → model → tool call (Preview) → tool response (Preview) → output
Model Guardrails 已是 GA；Agent Guardrails、controls／intervention，以及 tool call／tool response intervention 仍是 Preview。官方文件也指出，tool call／response moderation 只對列出的支援工具生效；自訂 Python function、MCP server 或未列出的工具，不能自行推論已被涵蓋。
還有一個很容易踩到的設定語意：Agent 指派自己的 guardrail 時，會完整覆寫 underlying model guardrail，不是把兩份設定自動合併。只有 Agent 未指派 custom guardrail 時，才會繼承 model deployment 的設定。
部署檢查還要讀回 controls、risks、四個 intervention points、actions 與 tool coverage。只有 guardrail ID，無法確認實際設定涵蓋了哪些路徑。
下面的 GuardrailCoverage 是專案自訂的 Python dataclass。它用 ToolName enum 記錄哪些工具已納入本次組合測試，沒有讀取 Foundry Portal 的設定，也不是 SDK 類別：
from magic_panda_agent.guardrails import GuardrailCoverage
from magic_panda_agent.models import ToolName
coverage = GuardrailCoverage(
supported_tools=frozenset(
{
ToolName.GET_EXPENSE,
ToolName.APPROVE_EXPENSE,
ToolName.EXPORT_EXPENSES,
}
)
)
Composition 的控制流程固定為：
def compose(*, pep, coverage_ok, content_hit, attack_hit):
if pep.effect != "allow":
return False, pep.reason_code
if not coverage_ok:
return False, "GUARDRAIL_COVERAGE_UNSUPPORTED"
if content_hit:
return False, "SAFETY_CONTENT_BLOCK"
if attack_hit:
return False, "ATTACK_SIGNAL_BLOCK"
return True, "ALL_LAYERS_ALLOW"
這段程式描述的是 decision precedence：PEP deny 先保留，PEP allow 才繼續檢查 coverage 與風險訊號。它沒有規定每個布林值必須按什麼時間順序計算；所有工具仍需要自己的 application PEP decision。
真正執行時，principal、request digest 與目前任務的 grant 由 server 的狀態和流程建立。有 capability、卻缺少本次操作意圖的請求，仍不能因 detector clear 就通過。這版 coverage key 只看工具名稱，還分不出 integration、provider、proposal source 或 request／response 路徑。
接著查看命令輸出的逐筆摘要，確認 PEP、訊號、coverage 與 Receipt 次數都留得下來。
每列保留 case、actor、object、tool，三個 signal／coverage 布林值，以及原始 PEP、組合後的原因與 Receipt 次數。這份畫面只選出部分欄位，沒有展開訊號來源與版本、組合規則或完整事件鏈。
這一版把每個 case 存成不可變、帶版本的 LayeredDecision。Record 不只寫 blocked=true，還保存：
schema_version 與 record_digest。Acceptance 重新計算 record digest，核對 PEP action hash 與 canonical action。唯一執行的 D22-B01，Receipt 也要指向同一個 action hash。這能檢查本機紀錄彼此一致，但還不是數位簽章或防竄改儲存。
下面三張圖共用同一組本機重放結果。FOUNDRY_AGENT_GUARDRAIL_NOT_EXERCISED 表示這裡測的是 composer 與 PEP，沒有執行 Foundry Agent Guardrail：
先看內容無害的越權請求與外租戶物件操作，兩筆都應保留 PEP 的拒絕。
harmless_unauthorized 與 foreign_object_unauthorized 都顯示 actor／object／tool、application PEP reason 與 Receipt=0。內容無害不會繞過 capability 或 tenant 授權。
再看原本已授權的操作，遇到內容或攻擊訊號時如何被收緊。
harmful_but_authorized_test_text 與 attack_signal_on_authorized_action 分別顯示 content／attack signal、application PEP allow 與收緊後的 composed reason。風險分類與業務授權沒有被合併成同一個判斷。
最後確認未涵蓋的 MCP 工具被拒絕，同時保留一筆正常的唯讀操作。
unsupported_mcp_tool 顯示 coverage deny 與 Receipt=0；benign_authorized 則是 ALL_LAYERS_ALLOW，並產生唯一一張 read-only Receipt。安全測試也要保留合法控制組，否則全部拒絕不算成功。
從 day22/ 執行：
uv sync --frozen --extra dev
uv run pytest tests/stages/day22/test_acceptance.py -q
成功不是看到六個 blocked=true。正確 oracle 應包含五筆拒絕與一筆合法 read-only Receipt，並保留原始 PEP reason：
D22-A01 CAPABILITY_DENIED receipt=0
D22-A02 OBJECT_TENANT_DENIED receipt=0
D22-A03 SAFETY_CONTENT_BLOCK receipt=0
D22-A04 ATTACK_SIGNAL_BLOCK receipt=0
D22-A05 GUARDRAIL_COVERAGE_UNSUPPORTED receipt=0
D22-B01 ALL_LAYERS_ALLOW receipt=1 side_effect=0
external_calls=null cloud_calls=null
上面的欄位列出預期語意，實際驗收以 typed fields 為準。Day 22 的驗收記錄為 4 passed，涵蓋六筆 digest-bound records、bounded evidence、responsibility routing 與公開 rows 的欄位集合。
要重現第一張 responsibility matrix 使用的 JSON，可執行：
PYTHONPATH=src:. uv run python -c \
'import json; from magic_panda_agent.stages.day22 import responsibility_routing_evidence; print(json.dumps(responsibility_routing_evidence(), sort_keys=True))'
輸出只含六個 case 的 case_id、responsible_layer、composed_reason_code 與 receipt_count。另外六張 decision UI 則從同一個 bounded helper 取得資料：
PYTHONPATH=src:. uv run python -c \
'import json; from magic_panda_agent.stages.day22 import bounded_decision_evidence; print(json.dumps(bounded_decision_evidence(), sort_keys=True))'
今天的六筆合成案例把 content_signal、attack_signal、coverage 與 PEP reason 分欄，接 Foundry 時也要保留這個拆法。尤其是 tool call／response：先讀回 Agent 實際指派的 guardrail 和支援工具，再用命中與未命中的操作各跑一次，才能解釋「沒看到 intervention」究竟是未設定、未涵蓋，還是分類器沒有命中。無論哪種原因，業務 PEP 的決定都要能獨立對照 Receipt。
Microsoft Foundry readiness table 將 Model Guardrails 列為 GA，Agent Guardrails 與 controls／intervention 列為 Preview。Agent guardrail 的範圍是 Foundry Agent Service 建立的 agents，不包含僅登錄到 Foundry Control Plane 的外部 Agent。
NIST AI RMF 1.0 是自願採用（voluntary）的框架，也把 safety、secure and resilient、privacy 等特性分開。這與今天的資料設計方向一致：content signal、attack signal、coverage、PEP decision 與 Receipt 分欄保存，不只留一個 safe。若組織採用 ISO/IEC 42001:2023，可以再把 owner、監控與持續改善納入管理系統；integration coverage 仍要靠 deployment manifest 與回歸測試證明。
分層會增加延遲與 false positive，設定 rollout 也可能讓 Agent guardrail 覆寫原本的 model controls。支援工具清單、Preview 行為與底層 classifier 都可能改變。若測試只檢查「功能已啟用」，綠色設定頁反而會遮住沒有 coverage 的工具。
目前 lab 只用 tool enum 做 coverage，還分不出同名工具的不同 provider、integration 與 request／response path。若 MCP adapter 允許 caller 自稱 provider=azure-search，未來即使增加精確 key，也可能只是在認真驗證一個假身分。
這也說明 coverage 的身分資料需要由伺服器確認，不能只增加幾個 caller 可自填的欄位。下一篇接著看人工核准：流程停下來等人之後，如何讓人看到的交易和 executor 最後執行的內容一致。
iThome鐵人賽
看影片追技術