安全与监管已更新 2026-08-22 · 版本 1.0
沙箱化执行
在一次性的隔离环境中运行智能体生成或调用的所有内容，该环境不提供环境凭据，具有受限的文件系统、受控的出站流量和严格的资源上限。引入沙箱并不是因为智能体本身具有恶意，而是因为智能体的输入可能具有恶意。
证据: 行业观察置信度: 高来源: 行业观察来源: 个人经验来源: 论文
定义
沙箱化执行是指在隔离的临时环境中运行智能体生成的代码和智能体调用的操作。该环境的文件系统、网络、凭据和资源由宿主机而非智能体进行限制，从而确保被劫持或出错的智能体不会影响到沙箱外部的任何内容。
问题
在宿主机上执行代码的智能体会继承宿主机的属性：其凭据、文件系统和网络位置。此时，一次成功的注入或一个极其自信的错误命令，其后果与整台机器被攻破无异。
适用场景
每当智能体运行代码、执行 Shell 命令、安装包或处理不可信文件时，都应使用此模式。门槛很低：只要智能体能够触发执行，该执行就应当在沙箱中进行。
解决方案
使其具备临时性。为每个任务创建独立环境，并在任务结束后将其销毁，绝不传递下一个任务未要求的状态。持久化是单次攻破演变为长期据点的原因。
移除环境凭据。环境中的任何内容都不应仅仅因为存在即可被使用；仅在任务执行期间注入该任务所需的、范围严格受限的机密信息。
将文件系统限制在工作集内。仅挂载代码仓库或输入，不挂载其他任何内容，并将不需要写入的所有内容挂载为只读。
在沙箱内部限制出站流量，而不是在沙箱外围。从攻击者的角度来看，隔离和网络策略是同一种控制手段，而一个网络开放的沙箱就像是一个配有电话的监狱。
限制资源——CPU、内存、磁盘、实际运行时间（wall-clock）和进程数。资源失控消耗是最先且最常出现的失效模式，而且通常在没有任何对手攻击的情况下就会发生。
记录跨越边界的行为：哪些文件进入、哪些文件输出、访问了哪些目标地址。只有当您能看清什么通过了边界时，边界才是有用的。
组件
隔离原语：容器、microVM 或同等技术，根据工作负载所需的强度进行选择。临时生命周期管理，将销毁作为默认操作，而非作为清理步骤。限定于任务及其执行期间的机密注入路径。在沙箱边界内部应用的网络策略。由宿主机强制执行的资源配额和超时限制。边界日志记录：输入、输出和目标地址。
优势
- 将“智能体运行了恶意内容”这一安全事件转化为一个被废弃的容器。
- 使得赋予智能体真正的执行能力变得安全，而这往往是其发挥作用的关键所在。
- 既能限制无意的错误，也能防御恶意的攻击——同一种控制手段既能捕获死循环，也能拦截注入的有效载荷（payload）。
- 提供了一个干净的观测场所：任务所触及的一切都跨越了同一个边界。
风险
- 隔离性弱于预期：共享内核并不是防范蓄意逃逸的安全边界，将容器等同于 microVM 是一种概念性错误。
- 为了方便而暗中引入凭据——一个挂载的配置文件就会让整个模式功亏一篑。
- 由于重建缓慢，沙箱悄然变得持久化，从而失去了作为安全保障的临时性。
- 通过残留的共享界面逃逸：挂载的卷、编排器 API，或沙箱仍可访问的网络。
不适用场景
- 无执行能力的只读智能体，此时无需隔离，且引入沙箱无法带来任何收益。
- 对延迟极其敏感的内联路径，此时环境启动时间占用了任务的大部分时间，而更窄范围的控制（如受限的解释器、纯函数）会更合适。
- 当沙箱需要其本应扣留的凭据时，这表明该任务应该被拆分，而不是被隔离。
技术
ContainersmicroVMs (Firecracker / gVisor)Ephemeral workspacesResource quotas and timeoutsScoped secret injection
示例
- 一个编码智能体，为每个任务克隆到一个全新的容器中，挂载代码仓库，不提供云凭据，且出站流量限制在包注册表。恶意依赖项的安装只会销毁该容器，而不会产生其他影响。
- 一个数据分析智能体，在 microVM 中执行生成的 Python 代码，输入数据集挂载为只读，完全断网，并设有实际运行时间上限。生成的代码可能会出错，但绝不会产生高昂开销或泄露数据。
- 一个文档处理智能体，在一次性环境中打开不可信的 PDF 文件，因为上传文件中的解析器漏洞是通往宿主机的真实路径，且该文件来自外部。
KPI
- 沙箱化执行的比例
- 覆盖率指标。无论沙箱化部分的表现如何，在沙箱外运行的任何内容才代表了实际的安全态势。
- 沙箱生命周期
- 环境存活的时间。生命周期的延长意味着临时性正在向持久化侵蚀。
- 触及资源上限的次数
- 因配额或超时而停止的任务。这有助于识别失控的生成内容以及设置过紧的实际限制。
- 运行时存在的机密数量
- 环境中可访问的凭据数量。目标是任务所需的最小值，通常为零。
已观测到的失效模式
- 便利性挂载：为了让任务不再报错而挂载用户主目录、凭据文件或套接字（socket）。
- 持久化复用：由于重建成本过高，环境不再针对每个任务独立创建，导致状态和安全漏洞得以存留。
- 边界内开放出站流量：在网络自由开放的情况下，强隔离仅仅是对文件系统的限制。
- 编排器可达性：沙箱可以调用管理沙箱的 API，这属于设计上的逃逸，而非通过漏洞利用实现的逃逸。
经验教训
- 在信任生成内容之前，先隔离执行。沙箱是允许智能体运行代码的合理前提。
- 临时性才是安全属性；单靠隔离只能延缓问题的发生。
- 不存在的凭据无法被窃取——这也是发生逃逸后唯一有效的控制手段。
- 大多数沙箱的触发都是无意的错误，而非恶意攻击。这恰恰证明了该模式正在发挥作用，而不是它没有必要。
常见问题
- 容器足够安全吗，还是我需要使用 microVM？
- 这取决于内部运行的内容。对于存在注入风险的自有代码，一个无凭据且限制出站流量的加固容器通常是相称的。对于来自不可信来源的任意代码，应假定共享内核可以被逃逸，并使用 microVM。
- 这与最小特权工具有何不同？
- 最小特权限制了智能体可以请求的内容；而沙箱限制了在代码实际运行后发生的事情。前者管理请求，后者管理执行环境，运行代码的智能体两者都需要。
- 沙箱会降低运行速度。这值得吗？
- 请与替代方案的成本进行对比，而不是与零成本对比。大部分延迟来自于环境启动，这可以通过资源池和预热镜像在很大程度上消除；而它所防范的失效后果是运行智能体的宿主机被攻破。