论文提出在 Kubernetes 上保护 AI Agent 的七层纵深防御框架与参考架构

Kubernetes 运维智能体把读到的内容变成命令，模型不能当作安全边界。

• 场景：运维开始把告警分诊、日志与指标、补救、GitOps PR 和临时脚本交给 LLM 智能体。作者认为其行为由模型、提示词和进入上下文的全部内容决定，且不能可靠区分指令与数据。
• 现有不足：间接提示注入与 MCP 工具投毒已被演示。作者称即使有模型层防御，工具调用智能体仍易受影响。对齐与分类器只降概率，失败可被对抗发现。作者认为现有 Kubernetes 原语不是为智能体设计的，单独都不能处理数据/控制坍缩。
• 核心主张：应按多租户方式假定智能体敌对，约束其能到达、执行和外传的范围。作者引用 Willison 与 Meta：危害通常要同时有不可信输入、敏感或特权访问、对外通信或改状态；去掉任一腿即可收紧损害。三腿对应工具授权、RBAC 与出站。
• 本文给出：十类分类、九条原则、七层框架、EKS/AKS/GKE 参考架构，以及定性覆盖与四条走查。不涵盖训练时攻击、输出给人的安全或推理服务加固；模型提供者在信任边界外。
• 威胁模型：
  • 系统与资产：集群或管理集群内的运维智能体；资产为工作负载完整性与可用性、可达凭据、工具可见机密、记忆完整性与审计归因。
  • 能力：A1 内容注入，A2 恶意或被攻破的 MCP 服务器，A3 受影响的生成代码，A4 低权限内部人借智能体越权，A5 无对手的错误或反馈环。注入成功后假定工具选择与参数完全受控。
  • 信任：信任控制面、内核与运行时（取决于 RuntimeClass）、策略引擎、网关和身份提供者；不信任模型、智能体进程、上下文、检索内容、注册表外工具元数据与生成代码。

提示注入与设计层防御

• Greshake 等（2023）演示针对 LLM 集成应用的间接提示注入。
• Debenedetti 等（2024）的 AgentDojo 是评估工具调用智能体上提示注入攻击与防御的动态环境。
• Debenedetti 等（2025）的 CaMeL 用能力跟踪分离控制流与数据流。作者称本文 L6 在 Pod 与身份层采用这一想法。

智能体、MCP 与风险管理

• OWASP 发布智能体威胁与缓解、Agentic Applications Top 10、MCP 安全备忘单和 LLM Top 10。作者称 Table 1 在精神上与之对齐，并专门化到 Kubernetes。Cloud Security Alliance 的 MAESTRO（Huang，2025）给出智能体系统的分层威胁建模。
• Invariant Labs（2025）披露工具投毒；Hou 等（2025）与一篇 MCP 生态 SoK（2025）系统化相关威胁。作者称这些工作刻画威胁和一般缓解，本文贡献是映射到 Kubernetes 执行点与参考架构。
• NIST AI RMF 1.0（2023）提供组织级 AI 风险结构。作者称治理层是面向基础设施智能体的一种操作化。

云原生机制与智能体组件

• gVisor、Kata、Young 等（2019）的 gVisor 案例、VAP、OPA、Tetragon、Falco、SPIFFE 和 Sigstore 是已有隔离、准入、策略、运行时、身份与签名机制。
• Kubernetes SIG Apps 的 Agent Sandbox、CNCF kagent、Linux Foundation 的 agentgateway 把智能体构造带进 Kubernetes。
• 作者称本文的贡献是把这些机制组成一种姿态，使保证在智能体被完全攻破时仍然成立。

原则与协议

• Saltzer 与 Schroeder（1975）的最小特权和完全中介，以及 Hardy（1988）的 confused deputy，被用来框定 LLM 作为 deputy。
• Willison（2025）的 lethal trifecta 与 Meta（2025）的 Agents Rule of Two 用来定义致命组合。Yao 等（2023）的 ReAct 描述推理–行动循环。MCP 与 A2A 被作者视为工具发现、调用和智能体间消息的协议，常由网关做认证和按工具授权。

论文没有运行对照实验。Section 7.4 把无控制、仅提示词层防御、逐层单独加入和全栈列为未来消融，不是已完成的基线。作者把本文定位为：在模型不是安全边界的前提下，用 Kubernetes 原语和智能体组件重建数据/控制边界，并与模型层防御互补。

把运维智能体当作不可信租户。七层纵深防御（L1–L7）加治理层 G，把九条原则落到 Kubernetes 与常见开源机制；Fig. 1 为层次，Fig. 2 为参考部署。

设定与原则

• 循环与组合：工具结果回到上下文，工具在运行时选择，跨会话记忆可使注入持续。作者采用致命组合：不可信输入、敏感或特权访问、对外通信或改状态同时出现时损害才大；去掉一腿即可收紧。
• 原则：P1 控制须在智能体被完全对手控制时仍成立。P2 动作经网关或 API server 认证、按参数授权并记日志。P3 按任务类最小授权，优先只读。P4 自有身份，代用户时带委托权限且不超过请求者。P5 生成代码进无环境凭据的临时内核隔离沙箱。P6 默认拒绝出站，三腿共存须经人批准。P7 变更尽量走 GitOps。P8 一条 trace 串起请求、模型调用、工具调用、API 动作和审批。P9 限速、预算、熔断，自主按环境与风险分级。

L1–L3

• L1 身份：独立 ServiceAccount，不用默认账户；不调 API 的 Pod 关闭 automountServiceAccountToken；token 为受众绑定且短时。云侧用 EKS Pod Identity 或 IRSA、Entra Workload ID、GKE Workload Identity Federation，不用静态密钥。SPIFFE/SPIRE 用于网格身份。对 T3，网关做 OAuth 2.0 Token Exchange，降权 token 同时带用户 sub 与智能体 act，按交集授权；API 侧可用受限 impersonate，审计记下两个身份。
• L2 授权：命名空间 Role，写操作不用 ClusterRole；排除 pods/exec、secrets、serviceaccounts/token 和 RBAC 对象。VAP 约束对象内容，并可只匹配智能体身份。Listing 1：failurePolicy 为 Fail；用户名须以 system:serviceaccount:agents: 开头；拒绝改 kube- 前缀或 agents 命名空间、拒绝 DELETE、拒绝 replicas 为 0；Binding 动作为 Deny 与 Audit。作者称这由 API server 执行，绕过网关仍成立。智能体与沙箱命名空间使用 restricted Pod Security。
• L3 隔离：标准容器共享宿主内核。RuntimeClass 选 gVisor 或 Kata。Agent Sandbox 提供 Sandbox 资源及模板、claim 和预热池。Listing 2：不挂 SA token、非 root、只读根、丢弃全部 capabilities、摘要固定镜像；cpu 1、memory 1Gi、ephemeral-storage 512Mi，emptyDir 512Mi。按会话临时创建，专用命名空间且无 RBAC 绑定。作者称跨用户持久沙箱会成为 T7 通道。

L4–L6

• L4 网络：默认拒绝入站和出站，再放行 DNS、网关和模型端点主机名。作者称 IP 策略不够，需要 FQDN 策略（如 Cilium）。Listing 3 示例端口为 53、8080 和 443。沙箱通常无外部出站；要联网则经检查代理并审批。示例中智能体不到 API server，变更只经持有凭据的工具服务器。东西向 mTLS 来自网格或 SPIFFE。
• L5 工具中介：网关位于智能体与 MCP、A2A 及可选模型端点之间。开源例子是 agentgateway，经 kgateway 接 Gateway API。它认证调用者、对工具名和参数调用 OPA 或 Cedar、钉住工具元数据哈希（变化则隔离，作者称为 rug-pull）、拒绝易混淆工具名、记录决策并限速。Listing 4 允许范围内只读、只对批准仓库开 PR、生产破坏性动作要审批，并拒绝副本数 0。作者称与 L2 重叠是有意的。镜像用 Sigstore/cosign 签名并在准入验证。响应清洗被作者称为卫生措施而非边界。工具分 observe、propose、act。
• L6 数据：密钥不进上下文，由工具服务器经 External Secrets、Vault 或云密钥服务在服务端获取。日志工具先脱敏。记忆写入带来源和信任级，不可信工具输出不经审查不晋升；按租户和智能体分区，可时点回滚。作者称针对 T1，可用做法里以架构分离为最强：reader 只有只读工具且无出站，planner 不摄入原始不可信内容，动作仍过 L5。

L7、治理与三云

• L7 与 G：Tetragon 可在沙箱打开 token 路径时 Sigkill（Listing 5）；Falco 看意外 shell、连接和写文件。审计与网关拒绝用于告警。终止开关撤销身份绑定、缩到 0、加隔离网络策略并使网关会话失效。审批绑定工具与参数的哈希并过期。Table 2：Observe 在三环境均为 auto；Propose 为 auto，由人合并 PR；Act 为 Dev auto、Staging notify、Production approval；Destructive 在 Dev/Staging 为 approval，Production 由 L2 拒绝。预算和熔断针对 T8。作者称失控环是实践中最可能的危害，因为不需要对手（A5）。
• 三云：核心策略与云无关。作者称沙箱缺口最大：GKE 有托管 Agent Sandbox（gVisor、预热池、claim、沙箱默认拒绝网络），论文写预热池用于 sub-second 供给；AKS 为 Kata，runtimeClassName 为 kata-vm-isolation，需 Azure Linux 节点池；写作时 EKS 无托管沙箱，须自装 gVisor 或 Kata。FQDN 出站在 AKS、GKE 为原生，EKS 的 VPC CNI 不支持，需 Cilium 或出站代理。论文转述 Microsoft：AKS 过滤可能在每 Pod 大约 1,000 requests per second 以上下降；GKE 每个 FQDN 最多 50 个解析地址。身份都是无静态密钥的联邦，绑定声明处不同；作者认为应由平台团队声明式管理。Table 3 反映 late 2026 文档。模型端点示例为 Bedrock、Azure OpenAI、Vertex AI。

实验设置

• 性质：Section 7 为定性评估，含覆盖矩阵、四条走查、残留风险，以及提议但未执行的实证方法。作者写明不报告攻击成功率、延迟或成本开销。
• 材料：Table 1 定义十类威胁；Table 4 把威胁映到 L1–L7 与 G；S1–S4 为走查。论文未运行被测模型，也未执行数据集或基准。AgentDojo 只出现在未来方法中。
• 威胁类：T1 间接提示注入劫持目标，T2 工具误用，T3 confused deputy，T4 工具与 MCP 供应链，T5 不可信代码执行与逃逸，T6 数据与凭据外泄，T7 记忆投毒，T8 失控动作，T9 智能体间仿冒，T10 不可归因。对手能力为 A1–A5。
• 判定：走查按网关策略、VAP、出站、沙箱和运行时控制是否挡住该结果来讨论。论文未写评审模型、阈值、样本量或重复次数。
• 云映射：Table 3 把层次对应到 EKS、AKS、GKE 的文档能力，作者注明反映 late 2026 的供应商文档，不是部署测量。

主结果

论文没有可填数值的主结果。Table 4 用 • 标主要缓解、◦ 标辅助缓解，覆盖 T1–T10 与 L1–L7、G。文本转换后圆点与列无法可靠对齐，故不逐格转写。

作者主张	条件	出处
每类威胁至少两层缓解，且至少一层主要控制在智能体进程之外，不单靠模型行为	作者对 Table 4 的解读	Section 7.1
T1、T2、T6 有 L5，并有 L2 或 L4 的独立控制	注入驱动威胁	Section 7.1
未报告 ASR、延迟、开销	全文评估	Section 7

• 作者称单一误配置不至于使 T1、T2、T6 造成危害，因为工具边界的预防控制与另一执行点独立。
• 作者在 Limitations 写覆盖矩阵是评估而非测量，所以上表不是实测分数。
• 论文未报告任何模型、任何基准上的攻击成功率。

攻击走查

• S1（T1、T2）：受控工作负载写入日志，诱导把生产工作负载副本数设为 0。作者称日志由隔离 reader 读取，输出以引用数据到达 planner（L6）；若仍提议副本数 0，网关拒绝（L5，Listing 4）；网关误配置时 VAP 在 API server 拒绝（L2，Listing 1）；拒绝聚集告警（L7）。作者称须击败三个独立执行点才造成危害。
• S2（T4、T6）：已批准的第三方 MCP 服务器事后改工具描述，诱导读取配置密钥并经该工具参数带出。作者称网关发现元数据哈希变化并隔离（L5）；没有返回密钥的工具，也没有相应 RBAC（L2、L6）；该 Pod 在默认拒绝出站下到不了任意外部主机（L4）。作者称不可信输入与对外通信可出现在被攻破服务器上，但敏感访问这一腿缺失。
• S3 与 S4：S3（T5）中生成脚本试图读 ServiceAccount token 并利用内核漏洞。作者称沙箱未挂载 token（L1），Tetragon 在访问 token 路径时终止进程（L7，Listing 5），gVisor 或 Kata 另有内核边界（L3），无出站则不能拉取后续载荷或外传（L4）；残留风险是隔离运行时自身的漏洞。S4（T8）无对手，智能体反复重启失败原因在下游数据库的 Deployment。作者称每对象变更预算和熔断（G）在有界次数后升级给人，网关限速（L5）限制速率，审计基线标记突发（L7）。论文未给出这些次数的数值。

残留风险

• 判断与范围内完整性：作者称策略能禁止已知坏参数，不能判断允许的动作是否恰当；审批和 GitOps 把判断交给人，代价是延迟和审批疲劳。注入后仍可能给出误导摘要或有害 PR，作者称控制在审查质量而非基础设施。
• 模型通道与信任基：模型端点必须允许出站，上下文中的敏感数据按设计发给模型提供者。作者称合同与数据驻留控制适用，L6 减少进入上下文的内容。隔离运行时和策略引擎进入信任计算基。
• 策略漂移：作者称分层产生许多策略，其一致性本身必须被测试。论文未给出漂移发生率。

其他消融与分析

• 论文未运行消融。Section 7.4 提议改编 AgentDojo 的用户任务/注入任务结构，注入放在日志、事件、注解、ConfigMap、工单和 MCP 工具元数据，测量良性任务效用与定向 ASR。
• 提议的消融为：无控制；仅提示词层防御；每层单独加入；全栈。另提议关闭上层，核验 Table 4 所称的层间独立性。
• 提议测量网关与策略引擎的每调用延迟、有无预热池的沙箱获取时间，以及 gVisor 与 Kata 下系统调用密集负载的减速；作者称可在 Young 等（2019）的刻画上继续。
• 提议用各自主等级下每起事件的审批量与审批延迟代理审批疲劳。
• 以上由作者留待未来，本文没有对应数字。

作者指出的局限与后续方向

• 分析而非测量：作者在 Limitations 写，本文是框架与设计研究，评估是分析性的而非实证的（Section 8）。
• 矩阵与红队：覆盖矩阵反映的是作者的评估而非测量；制品未经过文中报告的红队演习（Section 8）。
• 版本变化：生态变化快，所引具体项目或 API 版本可能改变（Section 8）。
• 实证计划：Section 7.4 与 Conclusion 把定量验证留待未来，包括改编 AgentDojo 结构的集群注入基准（良性任务效用与定向 ASR；消融为无控制、仅提示词层、逐层、全栈）、关闭上层以核验下层独立性、网关延迟、沙箱获取时间、gVisor 与 Kata 减速，以及用审批量与审批延迟代理审批疲劳。
• 标准缺口：Discussion 写，工具调用授权请求的公共 schema、MCP 中签名且带版本的工具元数据、多智能体链中委托用户身份的传递，以及跨 OpenTelemetry span 追踪推理的约定，目前没有标准。作者称这些进展会使控制跨网关和框架可移植。

实验覆盖范围

• Section 7 包含 Table 4 的覆盖矩阵、四条走查 S1–S4，以及 Section 7.3 的残留风险讨论。
• 作者写明不报告攻击成功率、延迟或成本开销。
• Section 3 定义对手能力 A1–A5，Table 1 定义威胁 T1–T10。
• Section 6 与 Table 3 将各层映射到 EKS、AKS、GKE，并写条目反映 late 2026 的供应商文档，可用性随区域和集群版本变化。
• 论文未报告红队结果、每调用延迟、沙箱获取时间、系统调用密集负载减速、审批量或审批延迟；这些名称出现在 Section 7.4 的未来测量项中。

把 Kubernetes 上的运维智能体当作不可信租户，在假定提示注入已完全控制其工具选择的前提下，用基础设施重建数据面与控制面的边界。

要解决的是：智能体读日志、注解、工单或 MCP 工具描述时，这些内容可以变成它带着自身凭据执行的命令。模型对齐和分类器只降低概率。范围是基础设施运维，不是训练时攻击或推理服务加固。

方法是九条原则和七层控制，外加治理。身份按智能体拆分并委托用户权限；RBAC 与 VAP 限制动词和对象内容，包括禁止删除和把副本数设为 0；生成代码进无 token 的 gVisor 或 Kata 沙箱；出站默认拒绝，只放行模型端点等名单；网关对工具名和参数做策略，并钉住工具元数据；密钥不进上下文，reader 与 planner 分开；eBPF、审计和终止开关负责检测与停机。自主按 Table 2 分级。参考架构把沙箱、FQDN 出站和云身份分别绑定到 EKS、AKS、GKE。作者称写作时 EKS 没有托管沙箱运行时，FQDN 出站也不是其 VPC CNI 的原生能力。

作者没有测量 ASR 或开销。定性上，作者称每类威胁至少有两层、且进程外的缓解，T1、T2、T6 还有独立执行点。四条走查分别对应日志诱导缩容、工具描述变更后的外泄、沙箱内恶意代码，以及无对手的反复重启。作者称前三类要同时越过多层才能造成危害，第四类由预算和熔断停下。残留包括策略允许但并不恰当的动作、经模型端点的外泄，以及隔离运行时进入信任基。

作者的结论是：每个动作都应被中介，保证应在完全攻破下仍然成立，自主按动作类获得。作者认为最重要的下一步是 Kubernetes 原生注入基准，用效用和攻击成功率的消融来选择自主等级。