先说一个我最近排查的现场。客户把 AI Agent 部署在 Google Cloud负责自动处理工单、检索知识库还接了一个代码解释器。表象是Agent 偶尔会访问不该访问的路径。我上去一看运行时确实开了 gVisor容器也跑起来了日志里也有 sandbox 字样。但再往下翻发现他们把宿主机的 /data 目录整个挂进了沙箱读写权限而且没有配任何 seccomp profile。换句话说这个沙箱对 Agent 来说就是一层看起来很安全的包装纸实际上它想读什么读什么想写什么写什么。Google Cloud 官方材料里反复强调沙箱的核心作用是给不可信代码建立一个受限运行环境。但我在实际项目里观察到的真实情况是90% 的工程师第一次设计 Agent 沙箱时都把重心放错了地方。有人关心会不会被逃逸有人关心日志审计却很少有人先回答一个基础问题沙箱的边界到底画在哪这篇文章我不打算复述官方文档按照我这几年在 Google Cloud 上做 AI Agent 基础设施的经验把 AI Agent 沙箱背后的 5 个核心真相拆开讲清楚。每个真相都对应一个实际踩坑场景憋着没写在文档里的那种。1. 真相一沙箱是边界工具不是安全监控器——第一个坑坑在哪1.1 90% 工程师踩坑的深层原因我先说结论大多数人对沙箱的期望是它能防住坏事但沙箱的设计目标是它能限制行为范围。防住坏事是 WAF、EDR、入侵检测那类产品考虑的事情限制行为范围才是沙箱的职责。沙箱本身不具备判断一件事是好是坏的能力它只是在执行你预先定好的边界规则。它不会说这个行为可疑我拦一下它只会说这个操作超出了预设白名单我拒绝执行。AI Agent 之所以必须装进沙箱是因为它的行为不可完全预测。模型生成的代码可能跑出你完全没想到的操作RAG 检索回来的内容里可能藏着恶意指令外部工具返回的数据可能诱导 Agent 执行危险动作。既然行为不可预测我们只能在执行层面给它划一个圈圈内随便跑圈外一律禁止。判断圈外靠的是你写的规则沙箱不帮你聪明。那为什么说 90% 的工程师踩了第一个坑因为我看到绝大多数团队的沙箱配置流程是这样的先把 Agent 放进容器再开启 gVisor然后跑一个 Demo看到日志里出现 sandbox 字样就觉得我们已经接入了沙箱。但实际上边界规则一条都没写过。典型翻车配置我列几种对号入座看看容器使用--privileged模式或手动加了一堆高危 capabilities未配置 seccomp profile或直接设置为unconfined把宿主机根目录或大量业务目录挂载进沙箱且权限是 rw网络使用 host 模式或者 egress 策略是放行全部没有设置任何资源上限进程数、内存、超时时间全都不管这些配置下沙箱名义上存在实际上等价于裸奔。Agent 一旦执行了模型生成的恶意代码可以任意读写宿主机文件、访问内网服务、耗尽节点资源。更麻烦的是因为日志里确实有 sandbox 字样很多人会被这个假象迷惑排查问题时绕一大圈才想到沙箱可能根本没生效。1.2 边界设计从四个问题开始如果你要设计一个 AI Agent 沙箱最需要回答的是四个问题而不是研究逃逸攻击允许哪些系统调用Python 解释器、Node.js 运行时需要哪些 syscall是否允许 execve、socket、ioctl允许访问哪些文件系统路径模型权重放哪、知识库放哪、临时输出写哪允许访问哪些网络端点LLM API、外部工具服务、内网依赖允许消耗多少资源CPU 配额、内存上限、进程数上限、单次任务超时这四个问题分别对应对沙箱的核心构件seccomp/capabilities、mount/namespace、network policy、cgroup/timeout。如果你在这四个问题上没有明确答案那沙箱配置大概率是拍脑袋写的。我个人的习惯是先画一张信任边界图中间是 Agent 进程外面一圈是它需要交互的资源。然后逐个问这个交互真的必要吗必要的话最小开放范围是多少这么设计出来的方案和随手写的 Dockerfile 有本质区别。前者是你知道你隔离了什么后者是你希望它隔离了什么。2. 真相二Google Cloud 沙箱是分层积木gVisor 只是其中一块2.1 从容器到微虚拟机的隔离强度谱系Google Cloud 上做 Agent 沙箱可选的隔离层级不止一种。我按隔离强度排个序看表隔离方案原理隔离强度适用场景普通容器 seccomp/cgroups共享宿主机内核命名空间隔离中等低风险 Agent 任务、内部工具gVisor 用户态内核拦截系统调用Sentry 模拟内核行为较高运行模型生成代码的代码解释器微虚拟机 Firecracker每个实例独立内核高多租户场景、高安全要求 AgentCompute Engine VM硬件辅助虚拟化最高底层资源池、需要物理级隔离时很多人一提沙箱就想到 gVisor问我这是不是就是官方沙箱。准确地说gVisor 是 Google Cloud 沙箱技术底座之一。Cloud Run、Cloud Functions 这些无服务器产品确实默认在 gVisor 沙箱里运行容器但如果你在 GCE/GKE 上自己搭 Agent 平台那么隔离方案通常需要组合使用而不只是选一个运行时。这里的核心认知是隔离强度越高代价越大。微虚拟机启动一个实例要几百毫秒到秒级gVisor 启动通常更快但没有独立内核普通容器最轻量但共享内核。AI Agent 的任务形态多种多样——有些是毫秒级的函数调用有些是持续几分钟的代码执行有些是常驻的推理服务——不可能用一套隔离方案覆盖所有场景。2.2 生产级 Agent 沙箱的三层组合看官方架构建议加上我自己的落地经验生产级 Agent 沙箱一般是三层组合第一层进程级隔离Agent 的任务执行器跑在 gVisor 运行时里拦截系统调用。这一步解决的是模型生成代码直接操纵宿主机内核的问题。gVisor 的工作原理是在用户态实现了一个内核层 Sentinel应用发起的每个系统调用都会先经过它由它决定是模拟执行还是转发给真正的内核。这样即使 Agent 代码尝试执行 mount、ptrace 这类高危调用也走不到宿主机内核面前。第二层容器级边界每个 Agent 任务一个 Pod设置 resources limits、securityContext、network policy。这层解决资源隔离和策略下发。具体到 Kubernetes 上就是给 Pod 配置 requests/limits同时在安全上下文里把 capabilities 降到最低例如只保留NET_BIND_SERVICE其他全部删除。第三层VPC 级隔离Agent 沙箱集群放在独立 VPC/子网用防火墙规则限定它能够访问的内网范围。这一步最容易被忽视但恰恰是防止横向移动的关键。就算容器层和 gVisor 层都被攻破Agent 也访问不了同一网络里的数据库和生产服务。我见到过不少团队把精力全花在第一层绞尽脑汁配 seccomp 规则、研究 gVisor 参数却忘了把沙箱集群单独划分网络。最后 Agent 确实没逃逸但它用允许的网络路径把内网的 MySQL 扫了一遍。这不算逃逸但同样是事故。所以说gVisor 只是一个拼图块不是全部答案。沙箱是个系统工程每一层都有不可替代的作用也有覆盖不到的空隙层与层要互补。3. 真相三文件系统的最小可见程度决定了沙箱的真实隔离效果3.1 沙箱内文件系统的默认状态与挂载清单沙箱内的 Agent 进程看到的并不是宿主机完整文件系统而是一个经过裁剪的视图。默认情况下宿主机路径应该完全不可见。然后根据业务需要显式挂载必须的目录。一份合理的挂载清单应该长这样挂载项目标路径权限用途模型权重目录/models只读加载模型知识库目录/kb只读RAG 检索工具配置/config只读Agent 参数配置临时文件/tmp可写tmpfs任务中间产物输出目录/output可写任务结果我的经验法则是默认全部只读只有临时文件目录和最终输出目录可写。如果某个可写路径未来用不上就不要分配。这个原则听起来简单执行起来经常走样。实际工程里最常见的错误就是把可写范围不断扩大。Agent 要加载模型挂载整个模型仓库。Agent 可能要读取用户上传的文件干脆把上传目录挂进去反正只读。Agent 要保存结果再把数据目录挂成 rw。最后你会发现业务数据几乎全在沙箱的可写范围内一旦 Agent 被提示注入它可以篡改知识库、覆盖已有文件、往系统目录里写后门。正确做法是倒过来先明确最坏情况下 Agent 需要读哪些路径然后只挂这些路径且保持只读可写目录用 tmpfs 或者单独的空目录任务结束自动销毁最终产物通过一个受控的写出口收集这样即使逻辑上出了问题影响也被限制在最小的数据范围内。3.2 一个容易被忽略的信息泄漏面/proc文件系统隔离还有一个非常隐蔽的问题/proc目录。procfs 在 Linux 里是虚拟文件系统暴露的是内核和进程信息它跟普通挂在磁盘上的目录完全不一样。假设你的沙箱只是普通容器没有对 procfs 做特殊处理那么 Agent 里跑的任何代码都能通过/proc/1/cwd看到宿主机核心进程的工作目录通过/proc/self/mountinfo看到整个挂载拓扑甚至通过/proc/sys/kernel/*读取宿主机内核参数。这些都是敏感信息本来不应该出现在一个受限环境里。在 gVisor 场景下/proc是由 Sentry 模拟的不会直接暴露宿主机信息这一点相对安全。但如果你用的是普通容器 seccomp的组合就必须认真考虑对 /proc 的处理方式比如用只读挂载、隐藏子路径或者换用更严格的运行时。我给个实操建议做文件系统隔离验证时不要只测试能不能读 /etc/shadow那太基础了。多测试 /proc、/sys、/dev 这几个虚拟文件系统的暴露情况。很多伪沙箱就是在这个不起眼的地方露馅的Agent 没读到业务数据却把宿主机的进程列表和内核版本看得一清二楚这本身就是信息安全事故。4. 真相四网络隔离比文件隔离难得多断网不行不隔离更不行4.1 AI Agent 的网络依赖悖论沙箱设计里最头疼的部分不是文件系统不是系统调用而是网络。AI Agent 天生需要联网要调用 LLM API要访问外部知识源和搜索引擎要拉取依赖包要把执行结果上报。如果你把沙箱直接断网Agent 基本就废了模型再聪明也成了一个孤岛。可你要是把出站流量全部放开风险立刻冒出来模型生成的代码一旦被提示注入它可以利用网络访问内网服务、扫描同 VPC 的主机、读取云平台元数据。这里我要特别点名云平台元数据服务。Google Cloud 的实例上有一个metadata.google.internal地址普通请求不需要额外认证就能拿到实例的基础信息如果配置了 service account甚至能通过它换取访问 GCS、BigQuery 的临时令牌。如果沙箱网络没有任何限制Agent 生成的代码可以直接请求这个地址拿令牌然后用令牌去读取对象存储里的文件。这不是理论攻击是我在真实项目里看到过的攻击路径。4.2 四层网络隔离策略我在实践中把 Agent 沙箱的网络隔离拆成四个层次每一层解决不同问题默认拒绝出站沙箱容器默认没有 egress所有出站流量必须显式配置白名单没有白名单就一律失败。这样做的好处是即使 Agent 被诱导发起外部连接也会在第一时间被网络层挡住。域名/IP 白名单只放行 LLM API 域名、必要的工具服务域名。这里要注意白名单的粒度最好是域名而不是所有 HTTPS 流量否则等于没有限制。代理层管控出站流量统一经过一个 HTTP/HTTPS 代理代理层负责 DNS 解析过滤、目标地址校验和内容审计。这是我最推荐的一层因为代理天然有日志Agent 访问了哪些外部域名一目了然审计成本极低。VPC 防火墙兜底即使前两层都被穿透VPC 防火墙依然禁止沙箱访问内网非必要端口。这层是最后的保险丝也是最容易在前面配置的时候就顺手配好的。从实现角度看gVisor 会拦截 Agent 进程直接创建原生 socket 的尝试但这不等于网络策略自动生效。如果你在容器网络层允许了到0.0.0.0/0的路由那 Agent 照样能访问任何地址。沙箱的网络隔离必须和代理层、防火墙层组合单靠某一层永远不够。有一个细节值得单独提醒IPv6。很多团队只配了 IPv4 的防火墙规则忘了 IPv6结果 Agent 通过 IPv6 地址绕过限制访问了内网服务。做网络验证时v4/v6 都要测别给安全留下这样的后门。5. 真相五沙箱上线前必须验证隔离效果别等到出事了再排查5.1 一次遗漏 pids.max 的故障复盘前两年我处理过一个线上事故一个 AI Agent 执行模型生成的 Python 代码代码里有个死循环不断 fork 新进程。Agent 本身跑在容器里有 CPU 和内存限制但没设 pids.max。结果进程无限增长把整个节点的 pid 空间耗尽同节点上其他 Agent 任务全部调度失败最后宿主机都差点被打挂。排查的时候团队第一反应是沙箱为什么没拦住后来发现不是没拦住而是从来没验证过。我们当时默认了有 CPU 和内存限制就够了却漏掉了进程数限制、任务超时、文件句柄限制这些同样关键的维度。这个故障的责任不在沙箱在于我们没有把沙箱真的能限制一切该限制的东西当一回事。5.2 沙箱隔离验证清单现在我把 Agent 沙箱上线的验证做成一个标准化清单每次部署前都强制跑一遍文件系统验证在沙箱内尝试读取宿主机关键路径如 /root、/etc/shadow、其他业务挂载点预期全部拒绝。网络验证在沙箱内尝试访问 metadata API 和非白名单域名预期全部失败同时分别验证 IPv4 和 IPv6。系统调用验证尝试执行 mount、ptrace、reboot 等高危操作预期被 seccomp/profile 或 gVisor 拦截。资源验证运行一个快速消耗内存或无限 fork 的脚本确认 cgroup 能及时限制或杀掉进程且不影响宿主机。配置漂移检查用 IaC 工具管理沙箱配置定期比对实际配置与期望配置的差异防止参数被手动改动。下面这个简化的沙箱配置示例是拿 YAML 描述了一个比较合理的基线的样子实际使用时要结合你的 Agent 框架做调整sandbox: runtime: gvisor rootfs: read-only mounts: - source: /data/models target: /models read_only: true - source: tmpfs target: /tmp size: 2Gi read_only: false capabilities: - none seccomp_profile: default network: egress: deny allowlist: - api.example-llm.com - storage.googleapis.com proxy: sandbox-proxy.internal:8443 pids_max: 1000 memory_limit: 4Gi timeout: 300s还需要强调的是沙箱验证不是一次性工作。上游镜像更新、依赖升级、配置漂移都会让今天安全的沙箱明天变得不安全。所以隔离验证脚本一定要接入 CI/CD每次发版时自动执行。生产环境的沙箱配置不要靠人肉改用 Terraform、Helm 这类工具统一管理变更留痕随时能回滚。关于 AI Agent 沙箱我想说的就是这五个真相。最后分享一点个人体会做沙箱最忌讳的是配置一时爽上线火葬场。你花一个小时把 gVisor 打开、把挂载配上但如果没有花同样时间去验证边界是否如预期那这个沙箱就是薛定谔的沙箱——你以为隔离了实际可能没有。我这几年被这些坑教育过很多次现在设计任何 Agent 沙箱方案都会先问团队三个问题边界画在哪如何证明边界生效边界被打破时如何感知这三个问题能答上来沙箱才算是真正落地了。
先说一个我最近排查的现场。客户把 AI Agent 部署在 Google Cloud负责自动处理工单、检索知识库还接了一个代码解释器。表象是Agent 偶尔会访问不该访问的路径。我上去一看运行时确实开了 gVisor容器也跑起来了日志里也有 sandbox 字样。但再往下翻发现他们把宿主机的 /data 目录整个挂进了沙箱读写权限而且没有配任何 seccomp profile。换句话说这个沙箱对 Agent 来说就是一层看起来很安全的包装纸实际上它想读什么读什么想写什么写什么。Google Cloud 官方材料里反复强调沙箱的核心作用是给不可信代码建立一个受限运行环境。但我在实际项目里观察到的真实情况是90% 的工程师第一次设计 Agent 沙箱时都把重心放错了地方。有人关心会不会被逃逸有人关心日志审计却很少有人先回答一个基础问题沙箱的边界到底画在哪这篇文章我不打算复述官方文档按照我这几年在 Google Cloud 上做 AI Agent 基础设施的经验把 AI Agent 沙箱背后的 5 个核心真相拆开讲清楚。每个真相都对应一个实际踩坑场景憋着没写在文档里的那种。1. 真相一沙箱是边界工具不是安全监控器——第一个坑坑在哪1.1 90% 工程师踩坑的深层原因我先说结论大多数人对沙箱的期望是它能防住坏事但沙箱的设计目标是它能限制行为范围。防住坏事是 WAF、EDR、入侵检测那类产品考虑的事情限制行为范围才是沙箱的职责。沙箱本身不具备判断一件事是好是坏的能力它只是在执行你预先定好的边界规则。它不会说这个行为可疑我拦一下它只会说这个操作超出了预设白名单我拒绝执行。AI Agent 之所以必须装进沙箱是因为它的行为不可完全预测。模型生成的代码可能跑出你完全没想到的操作RAG 检索回来的内容里可能藏着恶意指令外部工具返回的数据可能诱导 Agent 执行危险动作。既然行为不可预测我们只能在执行层面给它划一个圈圈内随便跑圈外一律禁止。判断圈外靠的是你写的规则沙箱不帮你聪明。那为什么说 90% 的工程师踩了第一个坑因为我看到绝大多数团队的沙箱配置流程是这样的先把 Agent 放进容器再开启 gVisor然后跑一个 Demo看到日志里出现 sandbox 字样就觉得我们已经接入了沙箱。但实际上边界规则一条都没写过。典型翻车配置我列几种对号入座看看容器使用--privileged模式或手动加了一堆高危 capabilities未配置 seccomp profile或直接设置为unconfined把宿主机根目录或大量业务目录挂载进沙箱且权限是 rw网络使用 host 模式或者 egress 策略是放行全部没有设置任何资源上限进程数、内存、超时时间全都不管这些配置下沙箱名义上存在实际上等价于裸奔。Agent 一旦执行了模型生成的恶意代码可以任意读写宿主机文件、访问内网服务、耗尽节点资源。更麻烦的是因为日志里确实有 sandbox 字样很多人会被这个假象迷惑排查问题时绕一大圈才想到沙箱可能根本没生效。1.2 边界设计从四个问题开始如果你要设计一个 AI Agent 沙箱最需要回答的是四个问题而不是研究逃逸攻击允许哪些系统调用Python 解释器、Node.js 运行时需要哪些 syscall是否允许 execve、socket、ioctl允许访问哪些文件系统路径模型权重放哪、知识库放哪、临时输出写哪允许访问哪些网络端点LLM API、外部工具服务、内网依赖允许消耗多少资源CPU 配额、内存上限、进程数上限、单次任务超时这四个问题分别对应对沙箱的核心构件seccomp/capabilities、mount/namespace、network policy、cgroup/timeout。如果你在这四个问题上没有明确答案那沙箱配置大概率是拍脑袋写的。我个人的习惯是先画一张信任边界图中间是 Agent 进程外面一圈是它需要交互的资源。然后逐个问这个交互真的必要吗必要的话最小开放范围是多少这么设计出来的方案和随手写的 Dockerfile 有本质区别。前者是你知道你隔离了什么后者是你希望它隔离了什么。2. 真相二Google Cloud 沙箱是分层积木gVisor 只是其中一块2.1 从容器到微虚拟机的隔离强度谱系Google Cloud 上做 Agent 沙箱可选的隔离层级不止一种。我按隔离强度排个序看表隔离方案原理隔离强度适用场景普通容器 seccomp/cgroups共享宿主机内核命名空间隔离中等低风险 Agent 任务、内部工具gVisor 用户态内核拦截系统调用Sentry 模拟内核行为较高运行模型生成代码的代码解释器微虚拟机 Firecracker每个实例独立内核高多租户场景、高安全要求 AgentCompute Engine VM硬件辅助虚拟化最高底层资源池、需要物理级隔离时很多人一提沙箱就想到 gVisor问我这是不是就是官方沙箱。准确地说gVisor 是 Google Cloud 沙箱技术底座之一。Cloud Run、Cloud Functions 这些无服务器产品确实默认在 gVisor 沙箱里运行容器但如果你在 GCE/GKE 上自己搭 Agent 平台那么隔离方案通常需要组合使用而不只是选一个运行时。这里的核心认知是隔离强度越高代价越大。微虚拟机启动一个实例要几百毫秒到秒级gVisor 启动通常更快但没有独立内核普通容器最轻量但共享内核。AI Agent 的任务形态多种多样——有些是毫秒级的函数调用有些是持续几分钟的代码执行有些是常驻的推理服务——不可能用一套隔离方案覆盖所有场景。2.2 生产级 Agent 沙箱的三层组合看官方架构建议加上我自己的落地经验生产级 Agent 沙箱一般是三层组合第一层进程级隔离Agent 的任务执行器跑在 gVisor 运行时里拦截系统调用。这一步解决的是模型生成代码直接操纵宿主机内核的问题。gVisor 的工作原理是在用户态实现了一个内核层 Sentinel应用发起的每个系统调用都会先经过它由它决定是模拟执行还是转发给真正的内核。这样即使 Agent 代码尝试执行 mount、ptrace 这类高危调用也走不到宿主机内核面前。第二层容器级边界每个 Agent 任务一个 Pod设置 resources limits、securityContext、network policy。这层解决资源隔离和策略下发。具体到 Kubernetes 上就是给 Pod 配置 requests/limits同时在安全上下文里把 capabilities 降到最低例如只保留NET_BIND_SERVICE其他全部删除。第三层VPC 级隔离Agent 沙箱集群放在独立 VPC/子网用防火墙规则限定它能够访问的内网范围。这一步最容易被忽视但恰恰是防止横向移动的关键。就算容器层和 gVisor 层都被攻破Agent 也访问不了同一网络里的数据库和生产服务。我见到过不少团队把精力全花在第一层绞尽脑汁配 seccomp 规则、研究 gVisor 参数却忘了把沙箱集群单独划分网络。最后 Agent 确实没逃逸但它用允许的网络路径把内网的 MySQL 扫了一遍。这不算逃逸但同样是事故。所以说gVisor 只是一个拼图块不是全部答案。沙箱是个系统工程每一层都有不可替代的作用也有覆盖不到的空隙层与层要互补。3. 真相三文件系统的最小可见程度决定了沙箱的真实隔离效果3.1 沙箱内文件系统的默认状态与挂载清单沙箱内的 Agent 进程看到的并不是宿主机完整文件系统而是一个经过裁剪的视图。默认情况下宿主机路径应该完全不可见。然后根据业务需要显式挂载必须的目录。一份合理的挂载清单应该长这样挂载项目标路径权限用途模型权重目录/models只读加载模型知识库目录/kb只读RAG 检索工具配置/config只读Agent 参数配置临时文件/tmp可写tmpfs任务中间产物输出目录/output可写任务结果我的经验法则是默认全部只读只有临时文件目录和最终输出目录可写。如果某个可写路径未来用不上就不要分配。这个原则听起来简单执行起来经常走样。实际工程里最常见的错误就是把可写范围不断扩大。Agent 要加载模型挂载整个模型仓库。Agent 可能要读取用户上传的文件干脆把上传目录挂进去反正只读。Agent 要保存结果再把数据目录挂成 rw。最后你会发现业务数据几乎全在沙箱的可写范围内一旦 Agent 被提示注入它可以篡改知识库、覆盖已有文件、往系统目录里写后门。正确做法是倒过来先明确最坏情况下 Agent 需要读哪些路径然后只挂这些路径且保持只读可写目录用 tmpfs 或者单独的空目录任务结束自动销毁最终产物通过一个受控的写出口收集这样即使逻辑上出了问题影响也被限制在最小的数据范围内。3.2 一个容易被忽略的信息泄漏面/proc文件系统隔离还有一个非常隐蔽的问题/proc目录。procfs 在 Linux 里是虚拟文件系统暴露的是内核和进程信息它跟普通挂在磁盘上的目录完全不一样。假设你的沙箱只是普通容器没有对 procfs 做特殊处理那么 Agent 里跑的任何代码都能通过/proc/1/cwd看到宿主机核心进程的工作目录通过/proc/self/mountinfo看到整个挂载拓扑甚至通过/proc/sys/kernel/*读取宿主机内核参数。这些都是敏感信息本来不应该出现在一个受限环境里。在 gVisor 场景下/proc是由 Sentry 模拟的不会直接暴露宿主机信息这一点相对安全。但如果你用的是普通容器 seccomp的组合就必须认真考虑对 /proc 的处理方式比如用只读挂载、隐藏子路径或者换用更严格的运行时。我给个实操建议做文件系统隔离验证时不要只测试能不能读 /etc/shadow那太基础了。多测试 /proc、/sys、/dev 这几个虚拟文件系统的暴露情况。很多伪沙箱就是在这个不起眼的地方露馅的Agent 没读到业务数据却把宿主机的进程列表和内核版本看得一清二楚这本身就是信息安全事故。4. 真相四网络隔离比文件隔离难得多断网不行不隔离更不行4.1 AI Agent 的网络依赖悖论沙箱设计里最头疼的部分不是文件系统不是系统调用而是网络。AI Agent 天生需要联网要调用 LLM API要访问外部知识源和搜索引擎要拉取依赖包要把执行结果上报。如果你把沙箱直接断网Agent 基本就废了模型再聪明也成了一个孤岛。可你要是把出站流量全部放开风险立刻冒出来模型生成的代码一旦被提示注入它可以利用网络访问内网服务、扫描同 VPC 的主机、读取云平台元数据。这里我要特别点名云平台元数据服务。Google Cloud 的实例上有一个metadata.google.internal地址普通请求不需要额外认证就能拿到实例的基础信息如果配置了 service account甚至能通过它换取访问 GCS、BigQuery 的临时令牌。如果沙箱网络没有任何限制Agent 生成的代码可以直接请求这个地址拿令牌然后用令牌去读取对象存储里的文件。这不是理论攻击是我在真实项目里看到过的攻击路径。4.2 四层网络隔离策略我在实践中把 Agent 沙箱的网络隔离拆成四个层次每一层解决不同问题默认拒绝出站沙箱容器默认没有 egress所有出站流量必须显式配置白名单没有白名单就一律失败。这样做的好处是即使 Agent 被诱导发起外部连接也会在第一时间被网络层挡住。域名/IP 白名单只放行 LLM API 域名、必要的工具服务域名。这里要注意白名单的粒度最好是域名而不是所有 HTTPS 流量否则等于没有限制。代理层管控出站流量统一经过一个 HTTP/HTTPS 代理代理层负责 DNS 解析过滤、目标地址校验和内容审计。这是我最推荐的一层因为代理天然有日志Agent 访问了哪些外部域名一目了然审计成本极低。VPC 防火墙兜底即使前两层都被穿透VPC 防火墙依然禁止沙箱访问内网非必要端口。这层是最后的保险丝也是最容易在前面配置的时候就顺手配好的。从实现角度看gVisor 会拦截 Agent 进程直接创建原生 socket 的尝试但这不等于网络策略自动生效。如果你在容器网络层允许了到0.0.0.0/0的路由那 Agent 照样能访问任何地址。沙箱的网络隔离必须和代理层、防火墙层组合单靠某一层永远不够。有一个细节值得单独提醒IPv6。很多团队只配了 IPv4 的防火墙规则忘了 IPv6结果 Agent 通过 IPv6 地址绕过限制访问了内网服务。做网络验证时v4/v6 都要测别给安全留下这样的后门。5. 真相五沙箱上线前必须验证隔离效果别等到出事了再排查5.1 一次遗漏 pids.max 的故障复盘前两年我处理过一个线上事故一个 AI Agent 执行模型生成的 Python 代码代码里有个死循环不断 fork 新进程。Agent 本身跑在容器里有 CPU 和内存限制但没设 pids.max。结果进程无限增长把整个节点的 pid 空间耗尽同节点上其他 Agent 任务全部调度失败最后宿主机都差点被打挂。排查的时候团队第一反应是沙箱为什么没拦住后来发现不是没拦住而是从来没验证过。我们当时默认了有 CPU 和内存限制就够了却漏掉了进程数限制、任务超时、文件句柄限制这些同样关键的维度。这个故障的责任不在沙箱在于我们没有把沙箱真的能限制一切该限制的东西当一回事。5.2 沙箱隔离验证清单现在我把 Agent 沙箱上线的验证做成一个标准化清单每次部署前都强制跑一遍文件系统验证在沙箱内尝试读取宿主机关键路径如 /root、/etc/shadow、其他业务挂载点预期全部拒绝。网络验证在沙箱内尝试访问 metadata API 和非白名单域名预期全部失败同时分别验证 IPv4 和 IPv6。系统调用验证尝试执行 mount、ptrace、reboot 等高危操作预期被 seccomp/profile 或 gVisor 拦截。资源验证运行一个快速消耗内存或无限 fork 的脚本确认 cgroup 能及时限制或杀掉进程且不影响宿主机。配置漂移检查用 IaC 工具管理沙箱配置定期比对实际配置与期望配置的差异防止参数被手动改动。下面这个简化的沙箱配置示例是拿 YAML 描述了一个比较合理的基线的样子实际使用时要结合你的 Agent 框架做调整sandbox: runtime: gvisor rootfs: read-only mounts: - source: /data/models target: /models read_only: true - source: tmpfs target: /tmp size: 2Gi read_only: false capabilities: - none seccomp_profile: default network: egress: deny allowlist: - api.example-llm.com - storage.googleapis.com proxy: sandbox-proxy.internal:8443 pids_max: 1000 memory_limit: 4Gi timeout: 300s还需要强调的是沙箱验证不是一次性工作。上游镜像更新、依赖升级、配置漂移都会让今天安全的沙箱明天变得不安全。所以隔离验证脚本一定要接入 CI/CD每次发版时自动执行。生产环境的沙箱配置不要靠人肉改用 Terraform、Helm 这类工具统一管理变更留痕随时能回滚。关于 AI Agent 沙箱我想说的就是这五个真相。最后分享一点个人体会做沙箱最忌讳的是配置一时爽上线火葬场。你花一个小时把 gVisor 打开、把挂载配上但如果没有花同样时间去验证边界是否如预期那这个沙箱就是薛定谔的沙箱——你以为隔离了实际可能没有。我这几年被这些坑教育过很多次现在设计任何 Agent 沙箱方案都会先问团队三个问题边界画在哪如何证明边界生效边界被打破时如何感知这三个问题能答上来沙箱才算是真正落地了。
