上周在 KubeCon China 2026 做了一个分享《在多租户 Kubernetes 集群上大规模安全部署 AI 智能体》。讲完好几个朋友来问有没有文字版，今天整理了一下，发出来。

这次分享的是我们在 AKS 上搭建的多租户 Agent 平台，给工程师做日常开发、Oncall 值班和问题诊断用。内容主要侧重安全和治理，我把它们分成三块：为什么 Agent Harness 治理需要一个 Runtime、安全边界为什么不能放在 Agent Harness 里以及我们在构建过程中踩过了哪些坑、又学到了哪些经验教训。

Agent 改变了我们的工作方式

先说一个我们平台上每天都在发生的事。

我们团队分布在好几个时区。一个时区的工程师下班前把 issue 交给 Agent。人离线以后，Agent 继续改代码、跑 E2E，失败了接着修，然后创建或更新 PR。下一时区的同事上线时，接手的是一个已经有 PR、每一步都有记录的工作现场。

这给我们的工作方式带来了一个巨大的变化：Agent 不再是你指导一下它干一步的聊天工具，而是成了一个随时在线、持续推进任务的工作伙伴，Agent 的工作生命周期已经超过了人的在线时间。

不过任务继续推进，不代表 Agent 可以想干啥就干啥。它只能在授权的仓库、分支和策略范围里行动。碰到 Oncall 这种涉及生产的场景，变更和发给客户的消息还是要人确认才会发出。

所以人下线以后，Session、上下文和记忆得留在线上，Runtime 继续管着权限、预算和操作记录。说白了，会干活和能长期可控地干活，是两码事。

设计思路

这其实也对应着我们对 Agent 的设计，即应该把 Agent 的运行和 Agent 的治理放到两个不同的层面。如下图所示：

上层是 Agent Harness，GitHub Copilot、Hermes、OpenClaw 这些都在这一层，也包括你自己写的 Agent。它负责理解任务、选工具、执行动作，也就是整套系统的大脑。

下层是 Agent Runtime，一个隔离、安全的执行环境，让一个不可信的 Agent 能长期跑下去。它不仅管理着 Agent Harness 的生命周期、配额、成本和审计，也负责 Agent 身份和安全的治理。Runtime 对 Harness 是中立的，不替它思考，只管让它可靠、可控地运行。

架构原理

这两个层级对应到 Kubernetes 系统又是如何工作的呢？下面就是整个系统的架构图：

整个系统分为三层：

最上面是 Agent Runtime 控制面。Team 和 Skill 怎么共享，身份怎么授权，安全策略怎么定，Fleet 生命周期、预算和审计，都由控制面负责。这些策略都由管理员配置，Agent 看不到、改不了、更跳不过。

中间是实际干活的 Agent Instance，每个跑在独立的 Kata VM Sandbox 里。Sandbox 里面是 Agent Harness，搭配 MCP 和 Skills 的外置能力，加上自己的 Workspace、Session 和长期记忆。Sandbox 内部产生的所有数据都会持久化存储到 PVC 中，任何异常发生后重启都可以恢复到之前的状态。大模型调用和外部网络请求则分别经过 AI Gateway 和 Egress Gateway 的管控。

最下面是 AKS 集群，提供调度、持久化、Monitoring、错误恢复、准入控制和网络策略。

从这个图中，不知道你有没有注意到，我们 Agent Harness 单独跑在 Kata VM Sandbox 中，而所有的安全加固都放到了 Harness 的外面。这是为什么呢？

权限控制

来看一个在云平台上运行 Agent 时很容易犯的错误。

Agent 接到任务，打开 issue，评论区有一段看起来像正常排查步骤的话，让它跑一个脚本。Harness 觉得合理，选了执行工具，脚本跑起来了。脚本里多了一步，访问169.254.169.254，在云上这个地址就是 IMDS，返回的是这台机器云身份的 Token。拿到 Token，再发一个普通的 HTTPS 请求，就可能把 Token 泄露出去了。

单独看每一步都是正常的功能。整个过程发生在 Sandbox 里面，控制面和 Kubernetes 全程没参与。不需要容器逃逸，不会产生任何告警，甚至 Pod 状态一直是 healthy 的。但这已经产生了巨大的安全风险。

说实话，很早之前我用 AI 编程工具做开发的时候，就碰到过类似的问题。基本上主流的 AI 编程工具都提供了权限配置系统，我也试过在里面把curl 169.254.169.254 禁止掉。

但很快我就发现，Agent 太聪明了，发现 curl 命令被禁止后，使用 Python 写了个功能相同的脚本，权限配置很容易就被绕过去了。好在这个 IMDS 对应的 identity 没有授权任何云资源的访问权限，没有造成损失。

当时我不确定这算不算真正的安全边界，后来想明白了：一个控制，如果 Agent 自己能绕过去，它最多算纵深防御中给 Agent 的一层建议（Agent 可以选择不接受建议）。能当安全边界的控制，得跟 Agent 用什么工具无关，也不能被 Agent 改掉。

安全边界

所以这个问题的答案就是把控制放在 Harness 外面，具体分四层。

最里面是 Harness，以及进入其上下文的 MCP 和 Skills，全都是不可信输入。往外是 Agent Instance，也就是 Sandbox，代码在这里跑，隔离配置由 Runtime 创建，Harness 改不了。再往外是 Runtime，身份、权限、网络、预算和审计都在这里，Agent 碰不到。最外面是 Kubernetes，把这些约束执行出来。

回到刚才那条攻击链，里面两层看起来都是正常操作，都会放过。到了第三层，网络策略发现它要访问被禁止的地址，直接挡掉。这就是外层 Boundary 在兜底。

实践经验

了解了 Agent Runtime 的设计原理和安全边界之后，接下来再来分享一些我们在构建整套系统中的经验教训。

VM 安全边界

从刚才的安全边界部分你可以看到，每个 Agent 的 Sandbox 都是一个 Kata VM。为什么要到 VM 级别而不是选择用常规的容器呢？因为 Agent 跑的是自己刚生成的代码，会调编译器、构建工具、浏览器，没人事先知道它下一步碰哪个 syscall。

所以我们用 Kata VM 给每个 Agent 一层独立的 Guest Kernel，进程、文件、资源全都隔离在虚拟机中。就算 Agent 拿到 root 权限、甚至打穿 Guest Kernel，也出不了这台 VM，碰不到节点和别的 Agent。

当然要注意，虚拟化是有代价的：启动慢、密度低。不过跑的是不可信代码，这些代价可以接受。

你可能也经常听到要让 Agent 跑在 Sandbox 里面，那是不是说有了 VM 就足够了呢？当然不是的。VM 只管 Agent 的代码在哪儿跑。Agent 代表谁、能不能连到外网、花多少 Token、留下什么痕迹等等，Sandbox 都回答不了。这些得由 Agent Runtime 在外面管控。

给 Agent 一个身份

比如，要让 Agent 真正有用，得先让它能够访问我们的工作系统。问题也就来了，Agent 通过什么身份来访问呢？

最直觉的做法是让 Agent 直接复用用户的 Token，这样后面也省了再去单独给 Agent 配置权限。不过这儿有两个绕不开的问题：

• 一是 Agent 的权限等于用户的全部权限，它只想读一个仓库，却能碰到用户能碰到的所有东西。
• 二是审计日志里分不清哪一步是人做的、哪一步是 Agent 做的。

所以我们给每个 Agent 一个独立的 Agent ID，这是一个区别于用户身份的独立主体。Agent 启动时默认只有最基本的模型访问权限，用户来决定把哪些资源和操作授权给它，自己的身份不会交给 Agent。

实际执行每个 Action 时，Runtime 通过 OIDC Federation 用 Agent ID 换一张短期、限权、可撤销的云凭据。这样即使凭据被滥用，能拿到的权限和存活时间都有限，每次访问也都能追溯到具体的 Agent 会话和授权来源。

不过身份和权限只解决了“能不能做”的问题。还有一个问题是“能不能到达”，这就需要网络层面的控制了。

网络可达性控制

实际系统的访问通常有两道门：第一道门是检查有没有权限，第二道门则是平台有没有为这次操作开一条网络路径。两道门都过了，访问才能真正发生。

具体做法是对 Agent Workload 默认阻断 IMDS、集群管理面和其他 Agent 的内部网段。为什么 IMDS 可以无条件封掉呢？因为我们的身份系统用的是 OIDC Federation，换凭据根本不走 IMDS，封掉它不影响 Agent 任何合法的云访问。出口则是默认允许，但配置一些禁止访问的目标。在出口 Gateway 上每条请求都留日志，发现异常目标就会加入黑名单。

那这些策略怎么保证不被绕开、不随时间漂移呢？

靠两类机制，Admission 和 Reconciliation：

• Admission 在 Agent Workload 进集群之前做检查，部署如果缺了平台要求的隔离、身份或网络配置，压根就创建不了。
• Reconciliation 负责持续校正，因为安全策略不是静态的，会随着异常检测持续更新。

有意思的是，做 Reconciliation 的也是一个 Agent，我们叫它 AdminClaw。它持续监控所有 Agent Instance 的状态和网络请求，发现异常先告警，能自主执行的只有管理员预先划定的一小组收紧动作（比如收掉一个目标、隔离或重启一个可疑的 Instance）。但放宽网络策略不在它的权限范围里，必须由人来操作。

Skill 的版本管理

接下来聊 Skill 这块。你大概也已经感受到了，Skill 正在成为 Agent 能力扩展的核心方式。但 Skill 的管理如果做不好，本身就会成为新的安全隐患。

我举一个我们实际碰到的例子。有位工程师很早就给自己的 Agent 写了一个 CI failure diagnosis Skill，分析测试日志和失败原因。挺好用的，同事们就开始复制过去用。后来发现里面一条规则会把网络超时误判成代码问题，作者很快修好了，但团队里已经有好几个副本，有人用新版有人用旧版，谁也说不清某个错误结论到底来自哪一版。

这件事让我意识到两个问题：第一，Skill 不能靠复制传播，它需要版本管理和发布机制。第二，Skill 也是攻击面的一部分，一条被篡改的指令跟着副本扩散到哪个 Agent，就借哪个 Agent 的权限执行。

所以我们做了一个 Skill Marketplace。每个人先在自己的私有 Skill 里迭代，稳定以后通过 PR 提交评审，通过才发布到 Marketplace 成为 Team 共享版本。代价是发 Skill 比复制粘贴慢一步，但换来的是 Team 里只有一个版本。再出类似的误判，不用猜每个人手里到底是哪一份了。

那一个 Agent 装哪些 Skill 又由谁来决定呢？答案是它所在的 Team。我们的 Team 模型分四层：最上面是平台管理员定企业级策略，往下是 Team 决定支持哪些 Harness 和 Skill，再往下是用户使用 Team 配好的能力，最下面是 Agent 实例各自跑在独立 Sandbox 里。

能力沿着这四层往下流。新的 Agent Instance 创建时自动加载 Team 允许的 Skill 列表，Marketplace 有更新时，Runtime 自动同步，没人需要手动 pull。更新在新的 Session 里生效，正在跑的 Session 不会中途被换掉 Skill。同时状态严格隔离，任何一个 Agent 都看不到另一个 Agent 的内部状态，哪怕它们属于同一个用户。

大规模 Agent 的运行和成本管控

最后一个维度是 Scale。在我们的场景下，规模问题主要体现在三个方向。

第一个是数量。平台服务的是整个工程组织，Agent 一多，要管的就不只是更多 Pod 了，还有更多身份、授权关系、Skill 版本、网络策略和 Session。

第二个是时间。比如 Oncall 的一次 incident 调查可能跑好几个小时甚至跨天，中间 Pod 可能重启过，但 Agent 还得继续，所有状态都持久化在 PVC 里。

第三个是委派，多个 Agent 开始互相委派任务，每次委派都增加系统复杂性，所有的会话历史都要持久化存储以备追溯。

你可能也注意到了，大规模 Pod 部署、升级、调度、持久化，这些恰好都是 Kubernetes 本来就在解决的问题。所以整套 Runtime 直接跑在 Kubernetes 上，StatefulSet、PVC、CRD、Autoscaler 用的都是原生能力，我们没有另外造一套调度系统。

不过 Kubernetes 管得了 Pod、卷和调度，管不了 Model Token。Agent 多了、跑的时间也长了，Token 消耗就成了一个必须单独管控的问题。

所以我们把所有 Agent 的模型调用统一收进了一个 AI Gateway。Sandbox 里面只有 Gateway 的地址，看不到真实的大模型 API 和 API Key。

AI Gateway 主要做了这么几件事：全链路追踪每次 Agent 调用；Token 统计、预算和限流来控制成本；输入输出内容过滤和 Prompt Injection 防护；如果配了多个模型，还能做负载均衡和故障自动切换。

三条经验

回头看这个过程，如果只留三条经验的话：

第一，Harness 里面全是不可信输入，包括 Prompt、评论、Tool 输出、Skill，还有 Agent 自己生成的代码，这些都可能被攻击者控制。所以放在 Harness 里的控制，Agent 能碰到就能改掉，最多算纵深防御中的一层建议（Agent 可以选择不接受）。

第二，真正的安全边界得跟 Agent 怎么行动无关。Sandbox 决定代码在哪跑，Agent ID 决定它以谁行动，网络策略决定它能到达哪里。这三样都由 Agent Runtime 在 Harness 外面执行，Agent Harness 看不到也改不了。

第三，一切得按无人值守来设计。Session 落在 PVC 里 Pod 重启还在，Skill 版本绑在 Session 上不会中途被换掉，Token 预算一旦超出，AI Gateway 直接停服，不用等人来关。人下线以后，Runtime 继续为 Agent 守着这些边界。

接下来的计划

上面讲到的 Sandbox、身份、网络可达性、AI Gateway、Skill 治理这几个维度，是这套 Agent Runtime 已经交付的基座。在这个基座上我们接下来还有几件事要做：Harness 插件化让大家可以接入自己的 Agent，按任务维度做更精细的身份和权限控制，Sandbox 插件化支持更多的 MicroVM 方案，以及接入同一集群里部署的推理模型。

这些核心能力我们正在准备完整开源，计划在未来几个月内正式发布。如果你也在 Kubernetes 上跑 AI Agent，或者正在琢磨 Agent 的安全治理问题，欢迎关注后续的开源进展。