當許多公司將 AI 應用從實驗室原型（Prototype）推向正式生產環境（Production）時，最常遇到的問題是：傳統的容器安全模型已經不足以應對 AI 工作負載。為了填補這個漏洞，Google Cloud 平台提供商開始推出專門針對 AI 的安全框架，其中 Google 最近發布的 GKE Security Blueprint（GKE 安全藍圖）提供了一個值得工程師參考的實作路徑。
AI 工作負載的安全挑戰是什麼
對於 Junior 工程師來說，首先要理解 AI 應用與傳統微服務的不同。傳統應用主要關注 API 權限與資料庫存取，但 AI 應用引入了新的攻擊面。例如，模型權重（Model Weights）是公司的核心資產，一旦外洩等同於遺失核心競爭力；而 Prompt Injection（提示詞注入）則允許攻擊者透過精心設計的輸入，誘導 AI 執行非預期的指令或洩漏敏感資訊。此外，當 AI Agent（AI 代理）被賦予執行程式碼或呼叫外部工具的權限時，如果缺乏隔離，可能會導致整個叢集被入侵。
Google GKE 的三層防禦體系
Google 提出的藍圖將安全分為三個維度，旨在建立一個開箱即用的安全層疊體系。
第一層是基礎設施安全。這解決的是硬體與網路層級的信任問題。Google 建議使用 Confidential GKE Nodes（機密 GKE 節點），這是一種利用硬體級記憶體加密技術的方案，能確保即使在 GPU（如 Nvidia H100）或 TPU 運算時，記憶體中的數據也不被非法讀取。同時，透過 Workload Identity Federation（工作負載身分聯合），讓 Pod 可以直接從雲端儲存空間獲取模型權重，而不需要在設定檔中存放長效的金鑰（Long-lived keys），降低了憑證外洩的風險。
第二層是模型完整性。傳統的 SBOM（軟體物料清單）只能記錄用到了哪些套件，但無法記錄 AI 使用了哪個版本的數據集或框架。因此，藍圖引入了 k8s-aibom，這是一個開源的 Kubernetes 控制器，能自動生成 AI 專屬的物料清單，讓團隊清楚知道模型是由什麼組成的。
第三層是應用層安全。針對 Prompt Injection，Google 推出 Model Armor 負責檢查輸入與輸出的內容是否包含惡意指令或敏感資料。而對於需要執行動態程式碼的 AI Agent，則建議使用 GKE Sandbox（基於 gVisor 技術）。gVisor 是一個輕量級的虛擬化層，它在容器與 Linux 核心之間建立了一道牆，即便 Agent 執行了惡意程式碼，也無法直接影響到宿主機。
實作路徑：從部署到治理
Google 建議企業採取分階段實施，而不是一次性全部套用。第一階段是部署（Deploy），重點在於建立基準控制，如啟用身分驗證與機密節點。第二階段是運作（Operate），著重於生產環境的硬化，例如實施簽名映像檔政策（Signed Image Policies）確保程式碼未被篡改。第三階段是治理（Govern），建立組織級的護欄（Guardrails）與自動化事件響應機制。
雲端廠商的共同盲點與觀點對比
雖然 Google、AWS 與 Microsoft 都推出了各自的 AI 安全框架，但業界對此仍有爭議。AWS 採取類似的層級防禦，並利用 eBPF 技術（一種能在核心層監控系統呼叫的技術）來偵測異常行為。然而，安全廠商 ARMO 指出，雲端原生的工具大多停留在工作負載的邊界（Boundary），能告訴你某個 Agent 是否有權限存取資料，但無法判斷該 Agent 當下的行為是否正常。
這意味著，單靠 IAM 權限管控是不夠的。真正的 AI 安全需要觀察 Agent 的行為基線，偵測其是否偏離正常模式，進而動態縮減權限。而 Microsoft 則更傾向於從身分角度切入，透過 Entra Agent ID 為每個 AI Agent 分配短效的獨立憑證，並使用 PyRIT 等紅隊測試工具在發布前主動挖掘漏洞。
總結與工程實務建議
對於開發 AI 應用的工程師而言，最核心的觀念是：Kubernetes 本身只負責調度與隔離，它並不理解什麼是惡意 Prompt，也不知道回應是否洩漏了個資。因此，傳統的 RBAC（基於角色的存取控制）與網路政策（Network Policies）依然必要，但不再足夠。
在實作時，應優先考慮將模型權重與憑證脫鉤，對執行外部程式碼的 Agent 必須強制隔離，並在應用層加入內容過濾機制。安全不是單一工具的安裝，而是在基礎設施、模型管理與應用監控之間建立的層疊防禦。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。