企業的真實狀況：模型不只一個

Day 13 的零改碼只對 Vertex AI 上的 Gemini 有效。但企業的真實狀況是：客服用 Gemini、內部工具接 OpenAI、某個部門在 GKE 上自架了 Llama、還有一個廠商的 SaaS 帶自己的模型。

要讓所有 LLM 流量經過同一份政策，就是 Day 3 講的「位置 B」——閘道層。Google Cloud 上有兩個現成的閘道可以掛 Model Armor：Apigee 與 GKE 的 gateway 擴充。

Apigee：API 管理層的政策

Apigee 是 API gateway，把 LLM 呼叫也當成一種 API 來管。Model Armor 以 policy 的形式掛在 proxy 上：請求進來先過 SanitizeUserPrompt policy，回應出去過 SanitizeModelResponse policy。

<!-- apiproxy/policies/MA-Sanitize-Prompt.xml -->
<SanitizeUserPrompt name="MA-Sanitize-Prompt">
  <TemplateName>projects/guardrails-lab-2026/locations/us-central1/templates/ma-standard</TemplateName>
  <UserPromptSource>{request.content}</UserPromptSource>
  <ContinueOnError>false</ContinueOnError>
</SanitizeUserPrompt>

ContinueOnError=false 就是 Day 4 的 fail-closed。這裡它是一個明確寫在政策檔裡的決策，而不是藏在 except: pass 裡——這正是閘道層的價值。

把 OpenAI 相容 API 掛進來

Apigee proxy 後面接的目標可以是任何 HTTP 端點。本系列示範接一個 OpenAI 相容的 API（可以是 GB10 上的 vLLM，用 Cloud VPN 拉進來，也可以是任何第三方）：

Client ──▶ Apigee proxy ──▶ [MA prompt policy] ──▶ target: https://<openai-compatible>/v1/chat/completions
                                                                        │
Client ◀── Apigee proxy ◀── [MA response policy] ◀─────────────────────┘

要處理的細節：OpenAI 格式的 messages 是陣列，要抽出最後一則 user 訊息（或依 Day 9 的結論送最後三則）給 policy，不能把整個 JSON 當成一段文字送。

GKE：叢集內的閘道擴充

在 GKE 上自架模型的場景，用 GKE Inference Gateway 的擴充機制把 Model Armor 掛在叢集入口。優點是流量不用出叢集去繞 Apigee，延遲更低。

apiVersion: networking.gke.io/v1
kind: GCPTrafficExtension
metadata:
  name: model-armor-ext
spec:
  targetRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: inference-gateway
  extensionChains:
    - name: ma-chain
      extensions:
        - name: model-armor
          service: modelarmor.us-central1.rep.googleapis.com
          # template 與 fail 行為設定

三種接法的對照

Week 2 走完，雲端線三種接法都跑過了：

雲端線做不到的事（Week 2 誠實清單）

轉進地端線之前，把 Week 2 發現的邊界列清楚，這張清單就是地端線存在的理由：

1. 資料要送出去：所有接法的掃描都在 Google 的區域內執行。資料不出境的場景無解。
2. zh-TW 攔截率：Day 9 實測的中英落差為【填入】個百分點。
3. PII checksum、可控還原：Day 11 的三個邊界。
4. 新註冊惡意網域：Day 12，清單比對的天生限制。
5. 系統提示詞改寫洩漏：Day 10，需要 L3。
6. 多輪鋪陳：無狀態掃描，Day 9 的兩種送法各有代價。
7. 判定不可解釋：命中回傳的是類別與信心等級，沒有「為什麼」。稽核追問時只能回「引擎判定為 HIGH」。
8. 版本由平台決定：filter 升版與退役時程不由你控制（Day 8）。

反過來，雲端線做得好的：維運零負擔、floor setting 強制力、五個過濾器開箱即用、跟 Vertex AI / Apigee / GKE 的整合深度。

明天預告

Week 3 開始，轉進 DGX Spark。Day 15：L1 確定性規則引擎——regex、checksum、denylist、結構檢查的實作，以及量測「多少流量在 L1 就結束」。

追蹤 AId3fend

本系列的架構圖、實測 demo 短片與每日重點整理，會同步發在 Instagram @aid3fend。掃 QR code 或點連結追蹤，有問題也歡迎直接私訊討論。

更多 AI 資安筆記：aid3fend.com