Week 2 開場：先搞懂它的三個概念

Model Armor 的文件看起來很大，但核心只有三個東西：template（政策）、floor setting（最低政策）、filter version（偵測引擎版本）。搞懂這三個，剩下的都是參數。

Template：一份可重用的政策

Template 是一組過濾器設定的集合，建立在專案的某個區域底下。呼叫 sanitize API 的時候指定用哪個 template，Model Armor 就依那份設定掃描。

一個 template 裡可以開的過濾器：

設計上的意義：同一個專案可以有多個 template，對應不同風險等級的應用。本系列會建三個：

• ma-baseline：只開 injection 偵測，用來量最低延遲。
• ma-standard：injection ＋ RAI（medium）＋ SDP basic，模擬一般企業應用。
• ma-strict：全部開、閾值拉到 low，模擬對外客服。

gcloud model-armor templates create ma-standard \
  --location=$MA_LOCATION \
  --rai-settings-filters='[{"filterType":"HATE_SPEECH","confidenceLevel":"MEDIUM_AND_ABOVE"},{"filterType":"HARASSMENT","confidenceLevel":"MEDIUM_AND_ABOVE"},{"filterType":"SEXUALLY_EXPLICIT","confidenceLevel":"MEDIUM_AND_ABOVE"},{"filterType":"DANGEROUS","confidenceLevel":"MEDIUM_AND_ABOVE"}]' \
  --pi-and-jailbreak-filter-settings-enforcement=enabled \
  --pi-and-jailbreak-filter-settings-confidence-level=MEDIUM_AND_ABOVE \
  --basic-config-filter-enforcement=enabled \
  --malicious-uri-filter-settings-enforcement=enabled

Floor setting：組織層級的底線

Template 是應用自己選的；floor setting 是組織、資料夾或專案層級強制的最低要求。任何 template 都不能比 floor setting 寬鬆——如果 floor 要求 injection 偵測開在 medium，template 設成關閉或 high 都會被拉回 medium。

這個機制解決了 Day 3 講的「位置 A 的工程師會關掉護欄」問題：開發團隊可以自訂 template，但關不掉組織要求的底線。

gcloud model-armor floorsettings update \
  --full-uri="projects/guardrails-lab-2026/locations/global/floorSetting" \
  --pi-and-jailbreak-filter-settings-enforcement=enabled \
  --pi-and-jailbreak-filter-settings-confidence-level=LOW_AND_ABOVE \
  --enable-floor-setting-enforcement=true

金融業客戶最在意的稽核問題「你怎麼證明所有應用都有最低防護」，floor setting 是雲端線的答案；地端線要自己做等價物（Day 21）。

Filter version：偵測引擎會更新，而且會退役

這是實務上最容易踩的坑。Model Armor 的偵測引擎有版本（filter v1、v2、v3…），template 建立時會綁定版本。新版本的偵測能力與判定行為都可能改變——同一個 payload 在 v2 是 medium，在 v3 可能變 high 或反過來。

寫這篇文章的當下，filter v3 已升為穩定版，v1／v2 排定於 2026 年 11 月底退役。這代表：

1. 現在建的 template 要確認綁的是 v3。
2. 已有的 template 升版前，要用 Day 6 的 eval 集重跑一次，確認閾值行為沒有漂移。
3. 升版是一個變更管理事件，要進 Day 4 講的簽核流程。

本系列所有數字都以 v3 為準，表格會標明。

兩個 API

• sanitizeUserPrompt：輸入端，掃使用者送進來的內容。
• sanitizeModelResponse：輸出端，掃模型回應。可以附上原始 prompt 作為 context，讓偵測有上下文。

回應結構長這樣（節錄）：

{
  "sanitizationResult": {
    "filterMatchState": "MATCH_FOUND",
    "filterResults": {
      "pi_and_jailbreak": {
        "piAndJailbreakFilterResult": {
          "matchState": "MATCH_FOUND",
          "confidenceLevel": "HIGH"
        }
      },
      "rai": { "...": "..." },
      "sdp": { "...": "..." }
    },
    "invocationResult": "SUCCESS"
  }
}

注意 invocationResult：它告訴你這次掃描本身有沒有成功。這就是 Day 4 講的失效偵測點——invocationResult 不是 SUCCESS 的時候，你的程式碼要走 fail-closed 路徑，不能把它當成「沒有命中」。

今天的第一組數字

用 ma-baseline 對 eval 集裡 D-zh（中文直接注入）跑一輪，只看有沒有通、延遲多少，攔截率明天才談。

明天預告

Day 9：prompt injection / jailbreak 偵測實測。六類語料各自的攔截率、confidence level 三檔的差異、以及中文與英文的落差。

追蹤 AId3fend

更多 AI 資安筆記：aid3fend.com