單一護欄從來不夠

Day 15 介紹了 ShieldGemma 與 Model Armor 的分工，這篇要把視角拉高一層：在 Agent 架構裡，護欄不是單一元件，而是一個多層體系。

回顧這週前面幾篇：Day13 的 VPC-SC 與 IAM Conditions 是權限層的護欄、Day14 的 Cloud Armor 是流量層的護欄，加上 Day15 談的內容層護欄（Model Armor / ShieldGemma），三者處理的是完全不同的風險。

三層護欄各自攔什麼

這張表的意義在於：沒有任何一層能獨自撐起防線。權限層擋不住語意攻擊、內容層擋不住權限濫用、流量層兩者都擋不住。真正的防護來自三層疊加。

內容層護欄的取捨：快與準

在內容層內部，還有一組取捨值得注意：託管護欄（Model Armor）快速好接但客製化有限，自建護欄（ShieldGemma）彈性高但要自己養。實務上常見的做法是快慢分離——用託管層做第一道快速過濾擋掉明顯違規，自建層做第二道針對企業特定政策的深度判斷。

但這樣做的成本是延遲會疊加。如果你的應用對即時性要求高（例如語音互動），可能需要接受只用單層、或是把第二層改成非同步的事後稽核而非即時攔截。

護欄本身也是攻擊面

一個容易被忽略的角度：護欄模型本身也可能被繞過或被攻擊。如果攻擊者知道你用哪一種護欄、用什麼政策，就可能針對性地設計繞過手法。這意味著護欄的政策設計不該完全公開，而且需要像其他防線一樣持續更新——呼應這個系列一再強調的：安全不是一次性設定，是持續調適的過程。

想看完整的護欄工程實作？

這篇談的是護欄在 Agent 防線裡的定位。如果你想看更完整的護欄工程實作——包含 Model Armor 的實測攔截率、ShieldGemma 的微調流程與效果驗證、三層護欄的 A/B 對照實驗、以及誤攔申訴與成本優化——我在另一個系列《30 天打造 AI Guardrails：從 Model Armor 到地端 ShieldGemma》有完整 30 天的展開。

這篇的檢查清單

• [ ] 是否已盤點自己的 Agent 架構中，權限層／流量層／內容層各有哪些護欄？
• [ ] 三層之間是否有明顯的空缺，讓某類攻擊完全沒有防線？
• [ ] 護欄的政策設計是否有持續更新機制，而非一次設定就不管？

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。
Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。