為什麼輸出端要管 URL

一個被間接注入成功的 RAG 助理，最常見的下手方式不是直接洩漏資料，而是在回應裡放一個連結：「更多資訊請見 https://…」。使用者點下去，釣魚頁面完成剩下的事。這是 LLM05（Improper Output Handling）在真實世界最常見的樣子，而且它繞過了所有針對「內容有沒有害」的偵測——那句話本身完全無害。

Malicious URI 過濾器

Model Armor 的 Malicious URI 過濾器比對回應中的 URL 是否在已知惡意清單。設定只有開關：

gcloud model-armor templates update ma-standard \
  --location=$MA_LOCATION \
  --malicious-uri-filter-settings-enforcement=enabled

測法

已知惡意 URL 不能亂用真的，本系列用兩種：

1. 安全測試用的標準測試網址（各威脅情資廠商提供的 test URL）。
2. 自建的「攻擊者網域」——註冊一個自己控制的網域，但這種不會在惡意清單裡，正好用來測邊界。

邊界

第二張截圖就是邊界：清單比對抓不到新註冊的網域。攻擊者針對你公司做的釣魚網域，上線第一天不會在任何清單裡。這個過濾器擋的是「已知壞蛋」，不是「所有壞蛋」。

補法（地端線 Day 15 實作，雲端線可用 SDP 自訂型別做一部分）：

• 允許清單：對外客服的回應只允許出現公司自己的網域，其他一律遮蔽。這比黑名單有效得多。
• 不在 RAG 來源裡的 URL 一律可疑：回應裡的 URL 如果不存在於本次取回的文件中，就是模型自己生的或被注入的。

Streaming sanitization

Day 3 留的問題：串流模式下怎麼掃。

Model Armor 提供 streaming 模式的 sanitizeModelResponse，可以把模型逐步產生的片段送進去，而不是等整段完成。

它用的是哪種策略

Day 3 列了三種：緩衝後放行、分段掃描、邊顯示邊撤回。實測要確認的是：

1. 每次送進去的是累積內容還是新增片段？
2. 判定 MATCH 的時候，回傳的是「這一段有問題」還是「到目前為止有問題」？
3. 跨段的攻擊（URL 被切在兩個 chunk 之間）抓不抓得到？

# bench/ma_streaming.py
async for chunk in llm.stream(prompt):
    buffer += chunk
    verdict = await ma.sanitize_response_stream(buffer)   # 或 chunk，依 API 語意
    if verdict.match:
        yield REDACT_AND_STOP
        break
    yield chunk

已顯示內容收不回來

不管 Model Armor 用哪種策略，有一個問題它解決不了：已經送到使用者畫面的 token 收不回來。分段掃描的本質是「掃過才放行」，所以前端拿到的永遠是已通過的內容——但前提是你的閘道真的在等掃描結果才轉發。

很多實作為了體驗，會先轉發再掃描，MATCH 之後才「撤回」。這在網頁上勉強可行（前端刪掉那段），在 API 對接的下游系統完全不可行。本系列的閘道實作（Day 21）採掃過才放行，並量測它對首 token 延遲（TTFT）的影響。

延遲的帳：Week 2 小結

Week 2 到這裡把 Model Armor 五個過濾器（RAI、injection、SDP、malicious URI、CSAM 永遠開）都跑過了。把每個過濾器單獨開啟時的延遲疊起來：

明天預告

Day 13：Vertex AI 上的 in-line 整合。到目前為止都是自己呼叫 sanitize API；明天示範用 floor setting 讓 Gemini 呼叫零改碼就套上 Model Armor，這是雲端線最大的維運優勢。

追蹤 AId3fend

更多 AI 資安筆記：aid3fend.com