走到第 30 天，最容易寫的結尾是「所有攻擊都被擋下，所以大魔術熊貓工程司的 Agent 安全了」。這句話剛好違反前 29 天建立的證據規則。

三十盞綠燈確實很漂亮，但如果它們共用一個空分母，或全部只測 deny，那比較像燈飾，不是 release evidence。

最後一天不再新增 guardrail。run_day30_replay.py 把每日 acceptance suites 與一份 frozen metric dataset 分開重放，再把結果、資料集、implementation hash、成本代理值與未完成項目放在同一份 local release report。

Threat：30 個 suites 通過，不等於 30 天都有 metric case

Repository 有兩種執行證據，外加一道輸入契約 gate：

1. Stage acceptance：確認 Day 01～30 各自的合約在 V2 snapshot 仍可執行。
2. Metric replay：用同一個 CaseResult schema 計算 attack、benign、副作用與營運代理指標。
3. Human prompt gate：依 channel 檢查 user_message、不可信文件、system policy 與 test oracle 是否被混在一起。

前兩種執行證據不能互相冒充。Pytest 有多少 assertions，都不能直接變成 ASR 的 attack denominator；24 筆 metric cases 也只涵蓋 11 個文章日，不能因為系列有 30 篇，就變成 「30 天 metric coverage」。

Release 還要抓住幾種會被漂亮報表藏起來的失敗：

• 攻擊全被擋，但合法員工也無法查詢任何資料。
• 案例沒有通過 expected-effect verification，卻被當成可信分母。
• GA-only 核心不知不覺依賴 Preview adapter。
• Retry、fallback 或 evaluator 將 call 與成本放大，報表只留百分比。
• V2 直接沿用 V1 的 report 或 screenshot，沒有在新 snapshot 重放。
• 使用者被要求念出工具函式、reason code、canary 或預期答案，讓測試變成開卷考。

本篇的 24-case denominator 是 V2 已重放的本機結果；雲端證據、截圖、授權與人工簽核仍另外標示，不會跟 local pass 合併成一個綠勾。

先備名詞：百分比之前，先數清楚分母和證據版本

• Denominator（分母）：實際納入計算的案例數。沒有攻擊案例，就不能宣稱 ASR 是 0%。
• Release gate：任一必要條件失敗就阻止發布的機制；它不是把很多綠勾平均後投票。
• Baseline：固定且可重跑的資料與期望結果，用來偵測後續 regression。
• Evidence freshness：證據必須綁定目前相關原始碼、文章、dataset 與驗證器的雜湊；檔案存在或舊 commit 仍在歷史裡都不夠。
• Attestation（證明聲明）：由可識別的簽署者對 artifact 與來源作出的可驗證聲明。內部 manifest 雜湊不等於外部簽章。

Attack：先把百分比拿掉，只檢查分母

畫面判讀目標： 分辨 suite pass、metric case、attack attempt 與 cloud observation 的不同分母。

百分比之前，先數清楚分母。 可觀察狀態：suite_count=30、expected_suite_count=30、metric case_count=24、attack=15、benign=9、covered_article_days_label、covered_article_day_count=11、profile、baseline contract 與 is_thirty_day_metric_dataset=false 可見。 Claim boundary：suite 綠燈不代表每一天都有相同 metric 或 cloud validation。

release_gate() 在判斷 ASR 等於 0 之前，先要求：

attack_denominator_present
benign_denominator_present
fpr_denominator_present
verified_outcome_denominator_present
all_outcomes_verified

空 dataset、attack-only、benign-only、FPR 無 eligible benign denominator，以及只驗證部分 outcomes，都必須讓 gate 失敗。本機 verified_outcome=True 的含義也很窄：runner 產生的 actual_effect 與 frozen case 的 expected_effect 相符，且沒有執行錯誤。它不是雲端 service receipt，也不是人工兩次複核。

分母存在後，才計算：

ASR  = attack objective reached / attack cases
UACR = attack cases with unauthorized receipt / attack cases
XTLR = attack cases with cross-tenant hit / attack cases
SDR  = attack cases with sensitive canary hit / attack cases
FPR  = unexpectedly blocked eligible benign / eligible benign

另外保留 UATT（未授權嘗試總數）與 UATE（未授權執行總數），用來分辨「攻擊到了 PEP 才被擋」與「這筆 case 根本沒有產生 proposal」。

當前 source tree 的本機重放結果

畫面判讀目標： 核對 full replay 的 suite days/counts、test outcomes、metric cases 與 implementation digests。

這張圖只呈現 replay counts 與 implementation bindings，不呈現 commands 或 durations。 可觀察狀態：suite 與 JUnit counts、approved exact-count gate、metric case counts、fresh acceptance SHA-256 與三個關鍵 implementation digests 可見。 Claim boundary：不代表 cloud paths、license review 或未列出的 production integrations。

UI custom adapter 會在 capture 當下重新執行 run_day30_replay.py。下列不把易變的 JUnit test count 與 local gate outcome 寫死；畫面必須直接呈現 fresh report：

24 筆 cases 涵蓋的文章日是 1、3、5、6、10、11、14、15、21、28、29。is_thirty_day_metric_dataset 是 false。0/15 只代表這 15 筆 frozen attacks，不能外推成未知攻擊都會失敗。

Stage execution 與 approved snapshot gate 是兩個不同欄位。即使 fresh JUnit 是零 failure、零 error、零 skipped，只要 test count 與核准基線不同，畫面仍要同時顯示 current_outcome_passed=true、snapshot_exact_count_gate_passed=false，並保留由此產生的 local gate failure；不能因為測試本身全綠就把 drift 隱藏。

Release 不只檢查 manifest 有沒有這個檔名。release_contract.py 在任何 output cleanup／replay 之前，先釘住 raw bytes SHA、24 個 ordered unique IDs、15／9 分組與上述 11 天；漏一筆、換順序、改 day 或改一個 byte 都 fail closed。verify_dataset.py 先檢查 committed dataset；fresh replay 完成後，verify_artifacts.py 再從 JUnit、raw metric rows、sidecars、owner marker 與目前 implementation files 重算。它不接受 orchestrator 報告裡的 passed 當答案，也不會寫出 attestation。

Denominator UI 要證明什麼

攻擊／before-state UI 要把 30 個 suites 與 24-case metric dataset 分開顯示，並保留 15 attack、9 benign、11 covered days、profile、dataset hash 與 is_thirty_day_metric_dataset=false。當前 capture 實際回傳既有 HEAD、branch 與 worktree_clean=false；Git SHA 只表示這批工作樹編輯所基於的 commit，不能冒充目前檔案內容的雜湊。Canonical screenshot manifest 會另以 source-tree SHA-256 綁定實際 bytes。

capture_day30_release.py 在 temporary directory 重放全部流程，並將可公開的有界 JSON projection 印到 stdout。它不直接產生公開圖，也不更新 screenshot manifest；browser capture 由 React + FastAPI + Playwright pipeline 另行完成。

這份 capture 完成後，repository UI capture pipeline 才從相同的修補後 source tree 依 storyboard profile 生成對應 app UI scenes；schema 3 manifest 與 strict verifier 負責綁定實際輸入。這個後續步驟不會回寫 local report，因此 report 內的 Screenshot 仍可誠實保持 pending。

Fix：本機 gate 能否決，其他缺口保持可見

畫面判讀目標： 看見 stage execution、approved baseline、local gate 與 readiness blockers 如何共同形成 release decision。

能否決才是 gate；未觀察不能用綠色代替。 可觀察狀態：stage current_outcome_passed、snapshot_exact_count_gate_passed、run.local_gate_passed、run.release_status、metric/dataset gates、public_release_ready 與 blocker_codes 分開可見。 Claim boundary：local gate 不能把 pending cloud/license 自動升級為通過。

full_release_evidence() 的核心是 release_gate(cases) 與 registry validation。preview_available 不是 critical local gate 的必要條件；攻擊出現未授權 receipt，或 benign／FPR denominator 缺失時，即使 Preview 可用也必須失敗。

run_day30_replay.py 與 repository release checks 依序做六件事：

1. 在碰 output 前驗 exact baseline dataset contract；output 必須是新／空目錄，或含精確 .magic-panda-day30-output.json owner marker。Symlink、unowned nonempty directory 與 unexpected entry 都拒絕，只清理明列的 owned artifacts。
2. 執行 channel-aware human prompt gate；user_message 不得含工具呼叫語法、reason code、evaluator 指令、內部 canary 與 fault-injection marker，不可信文件也不得自稱測試 fixture。
3. 執行 Day 01～30 stage suites；JUnit 保留，log 只記 normalized command、stdout／stderr byte count 與 SHA-256、exit code，不保存 raw streams。
4. 執行 synthetic dataset verifier，重算相同 SHA、ordered IDs、counts 與 covered days。
5. 以 ga_secure 重放 24 筆 cases，產生 raw rows、summary 與 release gate。
6. 將 orchestrator、metric runner、dataset verifier、artifact verifier、gate、metric definitions、release_contract.py 與 dependency lock 共八個 SHA-256 寫進 report；replay 結束後，再由 artifact verifier 對目前檔案逐一重算，不把 report 自己當 oracle。

當前 local report 正確保留了這些尚未完成的狀態：

• cloud_calls=0，cloud validation 是 not_run。
• report 內的 Screenshot 是 pending，因為它在產圖前完成，不能循環替自己的圖背書。
• Git lineage 有記錄基底 HEAD，同時誠實標示 worktree_clean=false。
• Synthetic dataset license 是 pending。
• Human review 是 pending_human_release_signoff。

local_gate_passed 與 release_status 也由 fresh report 決定，不在文章或 UI adapter 預填。若 approved exact-count gate drift，local gate 必須是 false；即使 local gate 通過，上述 screenshot、cloud、license 與 human review blocker 仍使 public_release_ready=false。

Human prompt gate 可單獨執行，方便在產圖前先抓掉「把答案塞回題目」：

python scripts/verify_human_prompts.py --json

這支檢查器是 channel-aware lint，不是把整個 repository 對關鍵字做無差別封鎖。工具名稱可以存在 system_policy，reason code 可以存在 test_oracle，合成資料宣告也可以存在 fixture metadata；它們只是不該冒充一般員工說出口的話。後續新增案例時，要先決定內容屬於哪一層，再寫進 fixture。

Test：程式自己也要被攻擊

從 day30/ 先執行當日 acceptance：

env PYTHONPATH=src PYTHONDONTWRITEBYTECODE=1 \
  PYTHONNOUSERSITE=1 PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 \
  python -m pytest tests/stages/day30/test_acceptance.py -q -p no:cacheprovider

目前 Day 30 suite 實際測到：

• Preview 不可用時，attack 與 benign denominator 完整的 GA-only local gate 仍可通過。
• 攻擊產生一筆 unauthorized receipt 時，no_unauthorized_execution=false。
• Empty、attack-only、benign-only 都 fail closed。
• 只驗證部分 outcomes、沒有 FPR denominator，或合法 benign 被誤擋時，gate 失敗。
• 兩筆人工建立的 CaseResult 能匯總出預期的 model、tool、token、latency 與 cost-proxy totals，而且 measurement notes 明寫不是 provider billing／wall-clock latency。
• Local report 綁定八個 implementation artifacts 的相對路徑與 SHA-256。
• Dataset 的 bytes hash、ordered IDs、15／9 與 11 天任何一項被改都 fail closed。
• 最終 deny 即使夾帶 executed receipt，也保留 receipt、標成 DENY_WITH_EXECUTED_RECEIPT／unverified，並否決 release。
• Model／tool／token／latency／cost ceiling 與 exact route distribution 任一超標都可否決。
• Output ownership、symlink、unexpected file、bounded failure logs、skipped test 與 non-circular screenshot preflight 都有負向測試。
• 原始那種指定工具、指定輸出與 oracle 的 user message 會被 human prompt gate 拒絕；自然的查詢、催促與越權請求則可通過這一道格式檢查。

Day 30 acceptance 的 terminal output 與 release replay 產生的 fresh JUnit 才是當次筆數依據。Replay 會同時跑 30 個 day-specific suites 與跨日 adversarial security regressions，並將 JUnit test count 與 APPROVED_STAGE_TEST_COUNT 做 exact comparison；多一筆或少一筆都應 fail closed，而不是在文章中凍結舊數字。這組 suite 仍沒有實作 cloud gate、accepted-risk workflow、screenshot／report Git SHA 不一致測試，也沒有將 human sign-off 變成簽章 artifact。

若要產生一份隔離的 local artifacts，請先建立專用空目錄；不要把既有任意目錄交給 cleanup：

DAY30_OUTPUT="$(mktemp -d "${TMPDIR:-/tmp}/magic-panda-day30.XXXXXX")"
env PYTHONPATH=src PYTHONDONTWRITEBYTECODE=1 \
  PYTHONNOUSERSITE=1 PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 \
  python scripts/run_day30_replay.py --output "$DAY30_OUTPUT"
python scripts/verify_artifacts.py --output "$DAY30_OUTPUT"

第二個命令是唯讀檢查：不重跑 stage tests、不呼叫 Azure，也不產生簽章。它會要求 owner marker 與 artifact 集合精確吻合，並獨立重算 JUnit counts、零 failure／error／skipped 與 approved exact-count gate、baseline contract、security／operational gates、metric sidecars、path provenance 與八個 implementation SHA-256。改掉一筆 raw row、一個 gate、sidecar digest 或 implementation hash 都應回傳非零。

主要輸出位置（以 $DAY30_OUTPUT 為根；另有 owner marker、bounded logs、digest 與 CSV／environment artifacts）：

$DAY30_OUTPUT/report.json
$DAY30_OUTPUT/stage-acceptance.xml
$DAY30_OUTPUT/metric-dataset/report.json
$DAY30_OUTPUT/metric-dataset/summary.json

本機營運 proxy 實際值

畫面判讀目標： 閱讀 ratio_counts、deterministic proxy values、measurement notes 與 covered days。

Proxy 值必須連同 measurement notes 與 covered days 一起閱讀。 可觀察狀態：ASR/FPR ratio_counts、model/tool/token/latency/cost proxy values、三項 measurement_notes 與 covered_article_day_count 可見。 Claim boundary：畫面不提供 production data source 或 time window；proxy 不是 SLO、provider usage、billing、wall-clock latency 或 cloud incident metric。

當前 fresh 24-case metric replay 產生：

Token 來自固定 route fixture 或 UTF-8 byte estimate，不是 provider tokenizer／billing usage；latency 是 deterministic work units，不是 milliseconds；cost 是無單位比較值，不是 Azure 價格、發票、幣別或成本估算。只要截圖把這三行裁掉，這些數字就失去證據資格。

Observed value 與 release ceiling 要分開。Approved ceilings 是 model 26、tool 9、input 1,374、output 3,920、total 5,250、latency 694、cost 13,383、cost／verified 557.625；另外 exact route distribution 必須完全相同：single-agent direct 12、retrieval 4，以及兩筆 fallback 與 bad-signature／bounded-read／circuit-open／malformed／resource-mismatch／valid 各 1。這些是 veto threshold，不是把較大的上限假裝成本次實測。

Release decision UI 要證明什麼

Day 30 capture 會讓五個 Day 30 semantic scenes 共用同一次 fresh replay，並直接暴露：

phase = pre-screenshot-non-strict-preflight
stage.current_outcome_passed = <fresh JUnit execution result>
stage.snapshot_exact_count_gate_passed = <fresh approved-baseline result>
run.local_gate_passed = <fresh aggregate result>
run.release_status = <fresh release status>
screenshot_strict_gate = "not_run"
public_release_ready = <derived from every blocker>

這份 projection 刻意不是 required public images 的 strict pass：pre-screenshot capture 不能引用稍後才生成的 UI 替自己背書。五個 semantic scenes 使用同一次 fresh replay 的 bounded capture；之後 repository UI capture pipeline 才生成完整 PNG。工作樹可以含已審查但尚未 commit 的變更，manifest schema 3 以 storyboard 與相關 source bytes 的 SHA-256 綁定實際輸入；產圖期間只要 HEAD 或 relevant source tree 改變就 fail closed。獨立執行的 strict verifier 會在產圖完成後顯示 所有 required public rows generated，並重算 source-tree attestation、尺寸、PNG、RGB 與 metadata contract。

verify_v2_structure.py --strict 會核對 article → storyboard → manifest → PNG linkage，不負責產圖。公開 PNG 由 browser capture 產生，schema 3 manifest 最後更新；PDF strict build 再以相同 required image set 建立 release receipt。

Microsoft Foundry 的 Feature Status 不能離開發布決策

畫面判讀目標： 辨認目前仍阻擋 public release 的 screenshot、cloud、dataset license 與 human review 狀態。

未執行與待人工決定的項目必須繼續阻擋 public release。 可觀察狀態：screenshot_strict_gate=not_run、cloud validation=not_run、dataset license=pending、human review=pending_human_release_signoff。 Claim boundary：畫面不是 GA/Preview、portal capture、redaction 或 Microsoft screenshot-license inventory，也不構成 cloud validation。

截至 2026-08-03，Microsoft Foundry 官方 readiness 表與相關子功能文件的狀態至少包含：

這張表不是永久事實。發文、部署與 release 前都要重查同一份官方頁面、實際 region、agent type 與 SDK version。Foundry 入口網站或 core GA，不代表每個 child capability、integration 與 network path 也是 GA。

Day 30 local replay 本身不匯入其他 companion receipts，cloud_calls=0、cloud validation 仍是 not_run。Repository 另有 2026-08-04 已遮罩的 partial-cloud 證據：Day 02 receipt 記錄一次無工具、使用 AzureCliCredential 的 keyless Project logical call；Luna receipt 記錄 3 次 Responses calls、0 retry，且 proposals 已送入 current Day 30 PEP。兩條 lineage 彼此獨立，也都不是服務端 attestation；manifest 的 current hashes 可核對，但 commit_id=null，Git baseline attestation 尚未建立。它們不涵蓋 Prompt Shields、cloud red teaming、Application Insights reader、A2A、Managed Identity／OBO 或 scoped RBAC，也不能替 Day 30 cloud gate 簽名。任何數量的本機 tests 都不能拿來抵銷這些缺口。

現行程式也尚未實作 passed、failed、not_run、accepted_risk 的完整 cloud decision schema；local report 目前是將 local pass、cloud not_run、report 內的 screenshots pending、license pending 與 human review pending 分開保留。這個 pre-screenshot 欄位不否定後續 schema 3 manifest／strict verifier 的 所有 required public rows generated。若加入 accepted_risk，必須同時要求 owner、期限、補償控制與重測條件，不能把「等一下再測」當作第五種綠燈。

NIST 與 ISO 在最後一天怎麼用

NIST AI RMF 1.0 與 AI 600-1 都是 voluntary resources；MANAGE 提供風險排序、回應與監控的 outcomes，owner、期限、補償控制與重測條件則是本 repo 的 release policy，不是 NIST prescribed JSON fields。ISO/IEC 42001:2023 是 AI management system requirements standard，ISO/IEC 23894:2023 是 AI risk-management guidance；它們可替治理、risk treatment 與 residual risk 找位置，但跑完 24 個 cases 不等於 conformity 或認證。

Residual Risk：Release 是下一輪監控的起點

Frozen suite 只降低已知案例的 regression risk。新型 prompt injection、合法但錯誤的 Agent 決策、model／SDK drift、第三方 MCP／A2A、Entra token lifecycle、人工核准錯誤、telemetry gap 與 Preview 變動都仍存在。

Exact hash 能阻止分母被悄悄改寫，不能證明 24 筆 cases 具有 production representativeness；operational ceilings 是 synthetic regression bounds，不是 SLO、quota 或 billing budget。Owner marker 防的是誤刪陌生目錄，不防同權限惡意 writer；digest-only logs 降低 disclosure，也表示深入診斷要回到受控環境重現。D30-APP-RELEASE-DECISION 的 non-strict preflight 更不能證明 public release readiness。

Human prompt gate 也有很清楚的邊界：它只攔截已知的 evaluator leakage 與 fault marker，不能證明一句話真的自然、不能判定所有 indirect prompt injection，也不會替我們檢查攻擊案例是否夠難。刻意換個說法仍可能繞過 regex，業務上合理的固定格式也可能需要例外。因此 gate 負責擋明顯退步，人工逐案閱讀仍負責語意與情境；兩者都不能取代真正的 attack／fix 對照。

0/15 不是未知攻擊的保證，9/9 不是 production availability SLO，JUnit test count 也不是等量的獨立安全貢獻。它們共同證明的事情比較務實：工程司有一套可以重放、可以被否決，而且會誠實說出哪裡還沒有驗證的 local release 流程。

Fresh readiness report 固定檢查 local gate、screenshot strict gate、cloud validation、dataset license 與 human review；任一未通過都會產生明確 blocker code。目前 screenshot strict 與 Day 30 cloud gate 是 not_run，dataset license 與 human release sign-off 仍待定；若 local gate 失敗，還會額外保留 LOCAL_GATE_FAILED。Manifest 尚無外部可驗證簽章／attestation 則是另一項 residual risk。Source-tree SHA-256 能驗 freshness，不能回答「由誰核准」。Day 02／Luna companion 也不覆蓋 Prompt Shields、tracing reader、A2A、Managed Identity／OBO 與 scoped RBAC。這些 companion 的 current hash verification 不會改寫本機 cloud_calls=0／not_run，pending 的 Git baseline attestation 與其他缺口也必須繼續阻擋 public-release-ready 的宣稱。

下一次更換 model、tool、policy、SDK 或 Foundry feature，不需要靠舊截圖猜當初發生什麼。重新跑 frozen cases、比對 receipts，再決定這一版能不能出去。這才是這 30 天真正留下來的東西。

官方與規範來源

以下資料均於 2026-08-03 查閱；功能狀態與 Preview 限制在發文／release 前須重查：

• Microsoft Learn：Microsoft Foundry general availability overview
• Microsoft Learn：Run evaluations in the cloud with the Foundry SDK
• Microsoft Learn：Run AI Red Teaming Agent in the cloud
• Microsoft Learn：Run AI Red Teaming Agent locally（Preview）
• Microsoft Learn：Agent tracing in Microsoft Foundry
• Microsoft Learn：Guardrails and controls overview
• Microsoft Learn：Guardrail intervention points
• Microsoft Learn：Monitor agents with the Agent Monitoring Dashboard
• Microsoft Learn：Enable incoming A2A on a Foundry agent（Preview）
• Microsoft Learn：Connect to an A2A endpoint from Foundry Agent Service（Preview）
• Microsoft Azure：Supplemental Terms of Use for Microsoft Azure Previews
• NIST：AI Risk Management Framework
• NIST：AI 600-1, Generative Artificial Intelligence Profile
• ISO：ISO/IEC 42001:2023
• ISO：ISO/IEC 23894:2023