Agent 要进企业，先得有个「安全屋」：一套从沙箱到身份的隔离方案

当 AI 应用从「生成内容」走向「自主执行」，企业面对的麻烦一下子变了味：模型会自己写代码、操作浏览器、调用 MCP 工具和内部业务系统。这听着很美好，但对企业基础设施来说，几乎每一个「能动手」的智能体，都是一个潜在的安全缺口。怎么让它既能干活、又不会捅娄子？一场技术大会上给出的答案，是把 Agent 关进一个层层设防的「安全屋」。

一分钟速览

• 企业级 Agent Infra 的核心矛盾，从「怎么运行 Agent」变成「怎么划定它的边界」。
• 方案提出四层隔离：计算沙箱、L3/L4 网络、L7 服务/API、统一身份。
• 以 Kubernetes Agent Sandbox 作可信执行环境，跑模型生成的未知代码。
• 用 OVN-Kubernetes 做多租户网络、Istio 做 L7 访问控制、Keycloak 做身份体系。
• 关键思路：把外部 API Key 从 Agent 中移出，改在出口网关处统一替换。

为什么传统隔离不够用

按照上汽集团 & 云计算中心架构师方宇晨在 QCon 上海上的分享，企业级 Agent Infra 面临几个核心矛盾：运行时隔离要求高——Agent 会运行模型生成的未知代码，需要同时保证文件系统和内核的隔离，传统容器隔离无法单独承担完整的安全边界；网络环境复杂——它既要访问互联网、模型 API，又要访问企业内部系统，需要独立的 L3/L4 网络隔离；权限控制严格——一个 Agent 能调用哪些 API，必须经过严格授权；凭证风险高——各类凭证一旦直接进入 Agent，理论上就可能被读取甚至泄漏。

四层边界，怎么搭

实践思路是搭一套「四层隔离」：

• 计算隔离：以 Kubernetes Agent Sandbox 作为可信执行环境，借助 gVisor/Kata 支持 Warm Pool、Template、Idle Reclaim、Snapshot 等能力，让沙箱成为承载 Agent 的运行时；
• L3/L4 网络隔离：用 OVN-Kubernetes 为不同租户建立真正独立的网络域，支持每租户独立逻辑网络、独立地址空间、独立路由域，租户间默认隔离；
• L7 服务/API 隔离：用 Istio Sidecar 配合租户级 Egress Gateway 构建 L7 访问平面，Envoy Sidecar 负责 mTLS、路由代理与遥测，控制面管好 7 层路径与权限；
• 身份隔离：用 Keycloak 建立统一的 Agent 身份体系，每个 Agent 有独立的 K8s Service Account，通过换取短生命周期 JWT Token 来控制访问。

还没解决的问题

方宇晨也坦言方案仍需改进：OVN-Kubernetes 的网络构建流程有待简化；Token 的管理逻辑需要对 Agent 透明；更关键的是，要把外部 API Key 从 Agent 中彻底移除，改为统一管理，并在 Egress Gateway 出口处完成替换——这样才能让凭证不落到 Agent 手里。

产品链接

• InfoQ 演讲内容
• Kubernetes 官网

趋势洞察

「Agent 安全」正在从一句口号，变成一套具体的工程基建。过去企业谈 AI 安全，多半停留在模型对齐与内容过滤；一旦智能体开始真正动数据库、调接口、发邮件，安全边界就必须下沉到网络、身份和凭证层。这套方案的思路——把智能体当作「零信任的租户」来管——很可能成为企业 Agent 落地的标准范式。毕竟，让 AI 干活的前提，是先让它在一个摔不坏、也逃不出去的地方干活。