Cloud Native Computing Foundation 本週發布了一份指引，對所有正在 Kubernetes 上部署 LLM 工作負載的團隊丟出了一個具體、有分量的主張：K8s 所提供的那些基礎設施原語（路由、網路隔離、pod 級 RBAC、密鑰管理）是必要的，但不足以獨立撐起 LLM 的安全。底下真正的觀察是：LLM 不是一種無狀態的算力工作負載。它是一個接受不受信任輸入，然後由自己決定接下來要不要叫工具、要不要輸出敏感資料、要不要按照 prompt 裡出現的指令去執行的系統。這套威脅模型，和「把這個微服務打包進容器再做隔離」根本不是一回事，它需要的控制是在應用與 prompt 這一層，而不是在叢集這一層。
CNCF 列出的「Kubernetes 做不到的事」很實用。Kubernetes 判斷不了一條 prompt 該不該放給模型，判斷不了一條回應裡是不是含有應當在送到使用者前就被遮蔽的敏感資料，也判斷不了模型在這一次具體請求裡該不該擁有某個工具的存取權。基礎設施層處理路由與 pod 隔離。應用層必須處理認證、授權、輸入驗證、輸出過濾、工具存取決策，以及「模型到底做了什麼」的稽核日誌。OWASP 針對 LLM 應用的 Top 10，就是目前可用的最佳故障模式清單，也是應用層控制必須對著一項一項處理的那張表：prompt 注入、敏感資訊外洩、供應鏈攻擊、資料與模型污染、不當輸出處理、過度代理、系統提示詞外洩、向量與嵌入層弱點、錯誤訊息、未加限度的消耗。如果你家 LLM 部署對這十項裡面的每一項都沒有明確的控制，那它跑在一個安全的 Kubernetes 叢集上這件事，並不會讓它變安全。
這件事剛好落在本週這裡覆蓋過的好幾篇共同構成的 2026 年大模式裡：agent 與 LLM 工作負載的治理層，正在成為一個獨立的、頭等的類別，既不屬於模型這一層，也不屬於基礎設施這一層。AWS 的 Agent Registry 交付的是「企業級目錄 + 稽核」的那一版；CNCF 交付的是「開放標準」的那一版，面向所有在 Kubernetes 上跑 LLM 基礎設施的團隊。Kubernetes AI Conformance 計畫在 2026 年下半年擴展，納入 Sovereign AI 相關標準，這一條直接接到英國那隻 Sovereign AI Fund 以及整條業界裡更廣義的主權主題上。對想在受監管或自託管環境裡部署 LLM 的打造者，「開源 K8s + AI-conformance」這條路，是一個能繞開超大規模雲廠商鎖定、同時又拿到實質安全結構的真實選項。對已經押在某家 hyperscaler 上的企業，AWS Agent Registry + Bedrock AgentCore 就是那個托管版的等價物。兩邊的技術棧未來會為同一份企業採購預算互相競爭。
對在 Kubernetes 上跑 LLM 工作負載的團隊，三件可以立刻做的事。第一，把你目前的部署對著 OWASP LLM Top 10 審一遍；如果這十項你都沒有明確命名的控制，先把「輸入驗證、輸出過濾、工具存取授權」這三塊上好，因為它們關掉的是最大的攻擊面。第二，在你的內部文件裡，把「基礎設施安全姿態」與「應用層安全姿態」分開寫；一份說「我們的 K8s 叢集是 CIS-benchmarked 的」的合規稽核，並不等於說「我們的 LLM 部署可以上生產」，這兩件事屬於不同的團隊、需要不同的技能。第三，盯一下 2026 年剩下幾個月裡 CNCF AI Conformance 這個計畫：今年稍晚會落地的 Sovereign AI 那批標準，很可能會成為受監管行業 LLM 部署的事實參考架構，提前跟著這份規格走，比它落地之後再追要划算得多。對跑在 hyperscaler 托管棧上的團隊，以上原則同樣適用，只是換一下產品名稱：Bedrock、Vertex AI、Azure AI Foundry 都有對等的「應用層控制面」，這些面是需要被主動設定的，不是預設就配好的。