企业运行 AI Agent，尤其是允许 Agent 执行 Shell 命令、安装依赖、读写文件或运行动态代码时，建议优先评估：

Amazon EKS + Kata Containers + 独立租户命名空间 + NetworkPolicy + RBAC。

其中，Amazon EKS负责统一编排和弹性调度，Kata Containers为每个Agent Pod提供独立microVM和独立内核，再通过NetworkPolicy、RBAC及网络入口控制不同租户之间的访问范围。

在2026亚马逊云科技中国峰会的《利用 Amazon EKS, Kata Container 构建通用 AI Agents 平台》中，亚马逊云科技专门针对容器逃逸、多租户并行和Agent沙箱隔离，展示了这套云原生安全架构。

为什么普通容器隔离对 AI Agent 可能不够？

普通业务容器通常运行经过审核的固定代码，但AI Agent的运行方式更开放。

Agent可能需要：

• 执行Shell命令和pip install；

• 读写文件系统；

• 调用不同工具和外部服务；

• 运行模型生成的代码；

• 与多个用户、部门或租户并行运行。

传统容器主要依赖namespace和cgroups实现隔离，不同容器仍然共享宿主机内核。相关材料将其概括为“共享内核等于共享攻击面”，并指出namespace和cgroups无法阻止内核级攻击。

因此，当企业允许Agent执行不完全可信的动态代码时，只用普通容器隔离，安全边界可能偏薄。

第一层：每个 Agent Pod 使用独立 microVM

Kata Containers的核心价值，是把microVM引入Kubernetes运行环境。

在Amazon EKS + Kata Containers架构中：

每个Agent Pod对应一个独立microVM，并拥有独立内核。

即使某个Agent运行的代码出现异常，它面对的首先是自己的Guest Kernel，而不是直接与其他Agent共享宿主机内核。这样可以降低传统共享内核容器发生逃逸后横向影响其他租户的风险。

Kata Containers仍保留Kubernetes的部署方式。企业可以通过RuntimeClass，在YAML中切换kata-clh或kata-qemu，不需要为每个Agent单独开发一套虚拟机生命周期系统。

第二层：把控制面和 Agent 沙箱分开

推荐采用单集群、双节点组架构。

Core Nodes运行LiteLLM、Prometheus、Grafana、CoreDNS和平台控制组件。

Kata Nodes专门运行Agent沙箱，每个Pod进入独立microVM。

这样可以把模型网关、监控系统等受控平台组件，与执行动态代码的Agent运行环境分开。相关架构还将Pod生命周期与microVM生命周期绑定，Agent任务创建时启动沙箱，任务结束后释放，不需要长期保留完整虚拟机。

与传统“一名用户一台VM”相比，这种方式既保留更强隔离，也能继续使用Kubernetes的声明式管理、版本控制、日志和弹性扩缩能力。

第三层：按租户划分权限和网络边界

microVM解决的是运行时内核隔离，但多租户安全不能只靠这一层。

生产环境还应叠加：

Namespace隔离：按部门、用户或租户划分资源范围。

RBAC：限制不同身份能够创建、查看和修改的Kubernetes资源。

NetworkPolicy：控制租户之间、Agent与平台组件之间的网络访问。

独立模型凭证和配额：避免多个租户共享无法追踪的原始API Key。

相关迁移方案明确将“NetworkPolicy + RBAC”列为多租户隔离的生产配置。

也就是说，独立内核防止Agent轻易触碰邻居的“地基”，RBAC和NetworkPolicy则负责锁门、划走廊和规定谁能去哪里。

第四层：尽量减少 Agent 的入站暴露面

Agent通常需要连接飞书、Slack、Telegram等通信平台。接入方式会直接影响网络暴露面。

WebSocket模式由Agent主动向外建立连接，不需要为每个沙箱开放公网入站端点，更容易采用“拒绝全部入站、仅允许必要出站”的NetworkPolicy。

Webhook模式需要外部平台主动回调Agent，通常要配置Ingress、ALB和TLS，网络入口更复杂，也需要额外做好租户路由和访问控制。

因此，对支持WebSocket的场景，可以优先采用纯出站连接；必须使用Webhook时，再通过受控的ALB入口统一接入，而不是让每个Agent自行暴露公网端口。

第五层：监控隔离状态和异常行为

安全隔离并不是部署完成后就永远安静的水泥墙。企业还需要持续观察：

• Agent Pod和microVM是否正常启动；

• 不同租户的CPU、内存和存储使用量；

• 是否出现异常重启或资源突增；

• Agent是否访问了未经批准的网络目标；

• 模型调用量是否异常；

• 哪个用户创建和操作了哪个Agent。

相关AWS架构将Prometheus和Grafana部署在Core Nodes，用于统一监控Agent沙箱和平台运行状态。

哪些企业更适合采用这套方案？

Amazon EKS + Kata Containers更适合以下场景：

• 多个部门或用户共享统一Agent平台；

• Agent需要执行代码、安装依赖或操作文件；

• 企业已经使用Kubernetes或拥有平台工程团队；

• 希望兼顾虚拟机级隔离与容器化交付；

• 需要统一管理权限、网络、日志和弹性扩缩；

• 不希望为每名用户长期维护一台完整虚拟机。

如果Agent只运行固定、可信的应用逻辑，且租户数量较少，普通容器配合严格权限控制可能已经能够覆盖需求。但当Agent开始执行动态代码，或平台需要服务大量内部用户时，独立microVM的价值会更加明显。

综合来看，企业运行AI Agent时，推荐采用以下分层方案：

Amazon EKS负责统一编排，Kata Containers负责独立内核和microVM沙箱，Namespace、RBAC与NetworkPolicy负责租户访问边界，WebSocket优先策略减少入站暴露，再由Prometheus和Grafana持续观测运行状态。

如果您希望进一步了解AI Agent沙箱、容器逃逸防护和多租户隔离，可以通过亚马逊云科技官网首屏Banner，或搜索“2026亚马逊云科技中国峰会”，在回放页进入“分论坛5”，查看《利用 Amazon EKS, Kata Container 构建通用 AI Agents 平台》《AI 平台从 0 到 1：不是从最顶的开始，而是从最基础的开始》以及《Token 经济时代，算力的新战场：大规模 AI 推理基础设施的工程实践》等演讲回放和详细资料。