云原生计算基金会(CNCF)发布的一篇博客文章指出，企业在Kubernetes上部署大语言模型(LLM)时存在一个关键的安全缺口，那就是尽管 Kubernetes 擅长编排和隔离工作负载，但它本身无法理解或控制 AI 系统的行为，由此形成了一类完全不同且更为复杂的威胁模型。
文章认为，LLM 引入了一类新的风险，因为它们处理的是不受信任的输入，并且能够动态决定行动方式，这与传统应用不同。在典型部署中，例如，通过 API 或聊天界面暴露一个 LLM，Kubernetes 可以保证 Pod 运行正常、资源状态稳定，但它无法感知提示词是否是恶意的、敏感数据是否泄露，或模型是否以不安全方式与内部系统交互。这会导致一种糟糕的局面，那就是，基础设施表面健康，而底层风险却未被发现。
CNCF 强调，基于 LLM 的系统必须被视为可编程、可决策的实体，而不仅仅是计算工作负载。当组织把 LLM 置于内部工具、日志、API 或凭据之前时，实际上是引入了一个可被提示词输入影响的新抽象层。这会打开一系列风险入口，例如，提示词注入、意外数据暴露以及对已连接工具的滥用，而这些威胁并非传统 Kubernetes 安全控制最初所要解决的问题。
这种转变反映了云原生系统更广泛的演进：Kubernetes 正越来越多地被用于运行 AI 和生成式工作负载。随着采用规模的增长，这个平台正在从最初管理无状态微服务的定位，被扩展到编排数据密集型、智能体驱动和推理密集型系统。然而，安全模型尚未完全跟上这些新场景。
虽然 Kubernetes 为调度、隔离和资源管理提供了强有力的基础能力，但它缺乏对 AI 系统施加应用层或语义层控制的内置机制。比如，它无法判断一个提示词是否应被执行、一个响应是否泄露敏感信息，或某个 LLM 是否应访问特定工具或 API。
这种局限凸显了在基础设施之外增加额外控制层的必要性。传统 Kubernetes 安全实践，如RBAC、网络策略和容器隔离，依然是必要的，但单独使用它们还不够。组织还必须引入 AI 特定的控制，包括提示词校验、输出过滤、工具访问限制以及应用层策略执行。
博客指出，当前正在出现对“AI 感知型平台工程”的需求，即把安全同时嵌入基础设施层和应用层。这包括引入诸如OWASP Top 10 for LLMs之类框架、落实策略即代码（policy-as-code），并建立约束模型与数据和外部系统交互方式的护栏机制。
行业讨论正越来越多地将其定义为：从传统威胁模型转变为行为与上下文感知的安全模型。关注点不再只是保护基础设施本身，而是控制智能系统在其中的行为。随着 LLM 演进为可执行动作的自治或 Agentic 系统，这些问题会变得更加重要。
CNCF 的分析对那些正在 Kubernetes 上快速采用 AI 的组织发出了警示：运行健康不等于安全。一个系统即便完全符合 Kubernetes 的最佳实践，也仍可能通过其 AI 层暴露出明显的风险。
主要技术与安全厂商正在收敛到相似的原则。行业指南越来越多地建议采用多层安全模型，结合运行时监控、human-in-the-loop 控制，以及围绕 AI 系统可执行动作的严格策略约束。一个一致观点是，LLM 绝不能被当作权威决策者，而必须在有边界的上下文中运行，并具备明确的护栏、持续验证和可审计性。
随着 LLM 采用加速，行业正被迫重新思考关于信任边界、工作负载隔离和应用行为的长期假设。由此形成的结果是一个新的安全范式：Kubernetes 仍是基础层，但必须叠加 AI 特定的治理、可观测性与控制机制，才能确保智能系统的安全可靠部署。
原文链接：
CNCF Warns Kubernetes Alone Is Not Enough to Secure LLM Workloads
