30 天，一句話回顧

如果只留一句話：Agent 的安全問題，多數不是模型不夠聰明，而是企業沒有把邊界設計清楚。 這 30 天談的每一個攻擊手法、每一道防線、每一個架構陷阱，最終都指向同一件事——當一個系統獲得自主決策權之後，「它能做什麼」必須由架構明確定義，而不是寄望它自己克制。

五週回顧

貫穿 30 篇的三條主線

第一條：從 POC 到生產的落差。 五大架構陷阱的共通點是「POC 階段完全看不出問題」——POC 環境資料是精選的、情境是受控的、Agent 數量是少的。等到上線、資料變真、規模擴大，風險才一次爆發。這不是技術問題，是判準問題。

第二條：GCP Security 控制的實戰對應。 每一個攻擊手法都對應到具體的 GCP 控制：Tool Abuse 對應 IAM Conditions、跨 Agent 連鎖攻擊對應 VPC-SC 與 Workload Identity、供應鏈風險對應 Binary Authorization。安全不是抽象原則，是可以部署、可以稽核的技術控制。

第三條：託管與自建的互補。 Model Armor 這類託管服務快速好用，ShieldGemma 這類開放權重模型則能針對企業自訂政策微調——兩者不是二選一，而是疊加使用的兩道關卡。

所有可複用資產索引

這系列留下的 Checklist 與對照表：Agent 威脅檢查清單（Day6）、紅隊發現與 GCP 控制缺口對照表（Day12）、藍隊防線與紅隊攻擊對照表（Day18）、五大架構陷阱上線前檢查表（Day24）、Agentic 風險框架閉環表（Day27）。建議收攏成一份企業內部的 Agentic AI 安全治理總表。

如果你也在追團隊的其他系列

這系列談的是「防線面對真實攻擊撐不撐得住」。團隊另外兩個系列分別處理「怎麼用 Google ADK 把 Agent 建出來」，以及「上線後怎麼用 Cloud Observability 看懂它在做什麼」——建構、攻防、觀測三個角度，處理的是同一個根本問題：Agent 的自主性是它的價值來源，也是所有困難的來源。

最後

謝謝跟著走完 30 天的每一位。這系列的內容來自我在金融、醫療、製造業客戶的實務顧問經驗，以及在 COSCUP、AADay 等場合分享過的研究成果。技術細節會過時——光是寫這系列的期間，就有好幾個服務改名或改變狀態——但底層的思考方式：責任邊界、威脅建模、分層防禦、持續驗證，會留得比任何一個服務名稱都久。

💡 關於作者 我是 Fngi，專注在 AI 安全與雲端資安領域。如果這篇對你有幫助，歡迎追蹤 Instagram @aid3fend，我在那裡分享更多 AI 資安的實務筆記與趨勢觀察。