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 都有对等的"应用层控制面"，这些面是需要被主动配置的，不是默认就配好的。