AI 沙箱执行代码的安全性取决于其隔离边界——而隔离边界只是答案的一部分。更好的问题是：沙箱实际上隔离了什么，仍然可能泄露什么？大多数沙箱能很好地阻止某些行为（进程级代码执行、对宿主机的任意文件系统写入），但默认会开放其他方面（出站网络、软件包安装、环境变量中的密钥）。理解这些差距，才能评估沙箱是否符合你的风险模型。
代码执行沙箱的“安全”意味着什么
代码执行沙箱中的安全性不是二元属性。它是一组控制措施，每项措施针对特定风险类别。当有人问“这个沙箱安全吗？”时，他们通常同时在询问几个不同的问题：
- 宿主机隔离：沙箱内运行的代码能否逃逸到宿主机系统？
- 租户隔离：一个用户的代码能否影响另一个用户的会话？
- 出口控制：沙箱内的代码能否访问互联网、内部服务或元数据端点？
- 密钥范围：凭证的访问范围是否超出了必要范围？
- 供应链风险：软件包安装是否会引入意外或恶意代码？
- 可审计性：能否事后重建代理的实际操作？
一个沙箱可能在宿主机隔离方面很强，但在出口控制方面很弱；出口控制很强，但密钥处理很弱。评估“安全性”需要分别检查每个维度，而不是接受诸如“容器化”或“基于微虚拟机”之类的单一标签作为全部答案。
隔离层对比
AI 代码执行沙箱主要使用三种隔离模型。每种模型提供不同的边界。
进程隔离
进程隔离使用操作系统级原语——Linux 命名空间、cgroups、seccomp 过滤器以及 AppArmor 或 SELinux 配置文件——来限制进程可以访问的内容。沙箱作为宿主机操作系统上的一个进程运行，共享宿主机内核。
它能阻止什么：对更广泛文件系统的访问、沙箱外的其他进程，以及被 seccomp 策略明确阻止的系统调用。
它不能阻止什么：通过共享漏洞提升权限的内核漏洞。seccomp 绕过或内核漏洞可能跨越宿主机边界。
何时适用：短生命周期、低风险、相对可信的代码，此时启动速度和可移植性比硬性虚拟机边界更重要。不建议用于运行来自外部用户的任意代理生成代码。
容器隔离（Docker/命名空间）
容器隔离通过更结构化的镜像模型、网络命名空间和卷挂载扩展了进程隔离。大多数基于 Docker 的沙箱实现在容器内运行代码，使用最小化镜像和受限的 seccomp 配置文件。
它能阻止什么：对宿主机的直接文件系统访问，对相邻容器的大部分网络访问（正确配置时），以及对宿主机进程的轻易访问。
它不能阻止什么：内核级漏洞仍然有效——容器共享宿主机内核。配置错误的卷挂载、过于宽泛的 seccomp 配置文件、--privileged 模式以及暴露的 Docker 套接字都可能使预期边界失效。
何时适用：当 seccomp 配置文件严格、镜像最小化、出口受限且未授予特权访问时，许多生产部署有效地使用容器进行 AI 代码执行。风险模型与微虚拟机不同，但通过精心配置是可以管理的。
微虚拟机隔离（Firecracker/gVisor）
微虚拟机隔离在每个沙箱中运行一个轻量级虚拟机，拥有自己的客户内核，通过 KVM 管理程序边界与宿主机隔离。Firecracker 是最常见的实现；gVisor（使用其用户空间内核）提供了不同的权衡。
它能阻止什么：客户内核漏洞不会传播到宿主机内核或其他客户机。宿主机攻击面减少到 VMM（虚拟机监视器），而 VMM 被设计为最小化。
它不能阻止什么：VMM 本身的漏洞（罕见但并非不可能）。网络、软件包和密钥控制仍然存在于虚拟机边界之外——微虚拟机隔离不处理这些。
何时适用：运行来自外部用户的不可信或代理生成的代码，需要考虑爆炸半径的多租户环境，以及可能执行任意 shell 命令或软件包安装脚本的工作负载。
| 隔离模型 | 宿主机内核共享 | 租户分离 | 启动开销 | 宿主机逃逸风险 |
|---|---|---|---|---|
| 进程 | 是 | 弱 | 最低 | 最高 |
| 容器 | 是 | 中等 | 低 | 中（取决于配置） |
| 微虚拟机 | 否 | 强 | 中等 | 低 |
什么仍能逃逸各边界
隔离模型解决了运行时代码执行问题。它不能自动解决通过其他路径进入或离开沙箱的问题。
出站网络：所有三种隔离模型都将出站网络访问留给策略配置。默认开放出口意味着沙箱内的代码可以访问公共互联网、云元数据端点（AWS 和 GCP 上的 169.254.169.254）、同一网络上的内部服务以及任意外部 API。无论隔离模型如何，这都构成了数据外泄路径、密钥检索路径和命令与控制路径。
软件包安装：apt install、pip install 或 npm install 从外部注册表获取并执行代码。如果沙箱允许软件包安装并开放出口，那么包名冲突、域名抢注攻击或依赖混淆攻击可能会引入恶意代码，这些代码将拥有沙箱的全部权限。隔离边界包含爆炸半径，但无法阻止安装。
共享状态：在多租户部署中，共享缓存、共享包注册表、共享模板镜像或共享文件系统挂载会在租户之间创建通道，从而绕过隔离边界。
环境变量中的密钥：代理进程可见的环境变量可被代理运行的任何代码读取。如果数据库凭证或 API 密钥位于环境中，那么沙箱及其执行或安装的任何内容都可以访问它。
出口与网络控制
出口是大多数沙箱最大缺口所在。开放出站互联网访问很常见，因为它方便——代理需要安装软件包、调用 API 和获取资源。但这也会带来风险：
云元数据端点：在托管云基础设施上，169.254.169.254（及其 IPv6 等效地址）提供实例元数据，包括 IAM 凭证。沙箱内具有开放出口的代码可以访问此端点并检索底层主机的凭证。
基于 DNS 的外泄：即使 HTTP 被阻止，出站 DNS 查询也可通过将数据编码到域名查找中来外泄数据。DNS 阻止需要在解析器层面进行过滤，而不仅仅是阻止到外部服务器的 TCP/UDP 53 端口。
内部服务：如果沙箱在私有网络网段上运行，开放出口可能允许访问内部数据库、管理面板和 API，而这些本不应从代理代码访问。
需评估的控制措施：
| 控制措施 | 它能阻止什么 | 需验证什么 |
|---|---|---|
| 默认拒绝出口 | 向未列出目的地的出站连接 | 它是否同时阻止 DNS 和 TCP/UDP？ |
| 基于白名单的出口 | 连接到非批准的域名 | 白名单是否可由客户配置？ |
| 元数据端点阻止 | 通过 169.254.169.254 获取云凭证 |
IPv6 元数据是否也被阻止？ |
| 出口代理 | 所有出站流量的日志记录和检查 | 代理日志是否可访问？ |
| DNS 过滤 | 基于 DNS 的外泄和内部名称解析 | 沙箱内部使用哪个解析器？ |
没有普遍正确的出口策略。某些代理工作负载确实需要广泛的互联网访问才能发挥作用。关键在于策略是经过深思熟虑且可审计的，而不是因为从未配置而默认开放。
密钥处理
AI 代理沙箱中的密钥遵循与任何软件系统中相同的原则，但多了一个约束：代理可能执行读取、记录或传输环境的代码，而开发人员并非有意为之。
范围限定：仅挂载沙箱当前任务实际需要的凭证。运行编码任务的沙箱不需要生产数据库凭证。评估模型输出的沙箱不需要计费服务的 API 密钥。
生命周期：短期凭证比长期凭证安全得多。如果密钥在沙箱内泄露，较短的 TTL 会限制暴露窗口。许多云 IAM 系统支持在几分钟或几小时内过期的短期令牌。
注入方式：环境变量是最常见的注入方式，也是最容易被进程中任何代码访问的方式。可以通过文件系统挂载注入的密钥、挂载在代理无需遍历的路径上的密钥，或仅在需要时动态获取的密钥，比宽泛的环境变量集更受限制。
脱敏处理：密钥应从 stdout、stderr、工具响应载荷、模型可见上下文和审计日志中脱敏。一个回显其环境、调用 env 或将令牌传递给失败 API 调用的代理，可能会将凭证泄露到日志中，而后这些日志会被存储或对操作员可见。
资源限制与拒绝服务风险
没有资源限制的沙箱容易受到代理工作负载的影响，这些工作负载可能耗尽 CPU、内存、磁盘或网络带宽——无论是由于失控代码、无限循环、已安装包中的内存泄漏，还是故意破坏相邻工作负载。
需验证的资源控制措施：
- CPU 限制：每个会话的限流或硬限制可防止一个会话独占宿主机容量。
- 内存限制：OOM 终止策略应终止沙箱会话，而非宿主机进程。
- 磁盘配额：每个会话的写入限制可防止一个会话填满共享存储。
- 执行超时：超过挂钟时间限制的会话应被干净地终止，而非继续运行。
- 网络速率限制：出站带宽限制可约束外泄，即使出口策略允许目标地址。
- 并发进程限制：大量分叉或生成后台进程的代理可能耗尽进程表槽位。
资源限制违规也值得记录。一个在执行本应轻量级的任务时持续达到 CPU 限流或 OOM 终止的会话，是一个值得调查的信号。
审计可见性
隔离控制在出现问题时减少爆炸半径。审计日志用于发现出现问题并重建发生了什么的途径。
具体到 AI 代理沙箱，有用的审计覆盖范围包括：
- 进程执行：运行的每个命令，附带完整参数列表、UID 和父进程。没有参数列表，日志中的
curl和python就没有意义。 - 文件系统访问：对敏感路径的读取和写入。对于大多数威胁模型，写入和删除比读取优先级更高。
- 出站网络：目标地址、协议、DNS 查询和传输字节数。DNS 查询日志记录常被遗漏，但很重要。
- 软件包安装：包管理器、包名、版本、源注册表和哈希值。
- 会话生命周期：创建、暂停、恢复、终止和清理事件，附带原因代码。
- 资源限制事件：OOM 终止、CPU 限流、超时终止。
收集机制与覆盖范围同样重要。沙箱进程内部生成的日志可能被权限足够的代理抑制或修改。内核级收集（通过 auditd、eBPF 或管理程序检测）在应用层以下生成，代理无法写入。
向任何沙箱提供商或项目提出的问题
在评估托管沙箱服务或开源沙箱框架时，请使用此清单：
隔离
- 每个代理会话是否拥有独立的隔离环境，还是多个会话共享执行环境？
- 使用何种隔离模型：进程、容器还是微虚拟机？
- 客户内核是否与宿主机共享？
网络和出口
- 出口默认开放还是默认拒绝？
- 出口策略是否可以按租户或按会话配置？
- 云元数据端点（
169.254.169.254）是否被阻止？ - 沙箱内部的 DNS 如何处理？
软件包安装
- 软件包安装默认是否允许？
- 安装是否可以限制为批准的注册表？
- 安装事件是否记录来源和哈希值？
密钥
- 凭证如何注入沙箱？
- 凭证是否可以限定范围，仅提供给需要它的特定工具或任务？
- 密钥是否从日志和模型可见输出中脱敏？
资源限制
- CPU、内存、磁盘和超时限制是否强制实施？
- 达到限制时会发生什么——限流、终止还是告警？
审计日志
- 日志是在内核/管理程序级别生成的，还是在沙箱进程内部生成的？
- 默认记录哪些事件类别？
- 日志是否可以导出到外部 SIEM 或日志聚合系统？
- 日志保留策略是什么？
租户管理
- 来自不同租户的工作负载是否彼此隔离？
- 是否存在共享缓存、镜像或挂载点，从而创建跨租户通道？
Novita Agent Sandbox 的定位
Novita Agent Sandbox 专为需要隔离执行环境的代理工作负载而设计，适用于代码、文件、进程和更长时间的运行会话。它面向构建编码代理、评估管道、数据分析代理和基于浏览器的代理工作流的团队。
该沙箱支持会话生命周期控制，包括挂起、恢复和空闲会话的自动挂起。它通过 API 提供资源指标和会话级执行日志。对于已经使用 Novita 模型 API 的团队，它可以作为代理架构中的执行层，其中模型进行规划和调用工具，而沙箱在隔离环境中处理运行时执行。
在评估 Novita Agent Sandbox 用于安全敏感用例时，请在做出架构决策之前，通过产品文档验证当前的隔离模型、出口策略默认值、日志覆盖范围和密钥处理方式。安全要求因工作负载而异——适用于内部评估管道的内容可能不足以处理处理用户提供代码的多租户产品。
与任何沙箱一样，安全状况取决于平台默认设置和应用层控制措施：凭证的作用域、代理被允许请求的内容、哪些工具调用需要人工审批，以及如何监控审计日志。
局限性及任何沙箱都无法消除的风险
没有沙箱能消除所有风险。理解边界外仍存在的风险与理解边界提供的保护同样重要。
应用层信任决策：沙箱控制运行时执行。它不能决定代理被允许请求什么。如果你的应用程序允许代理请求凭证、执行任意 shell 命令或调用任何 API，沙箱会减少爆炸半径，但无法阻止这些操作。
提示注入：处理不可信内容（网页、用户上传文件、外部 API 响应）的代理可能通过这些内容被操纵，从而执行不应执行的操作。这是一个应用设计问题，而不是沙箱问题。沙箱可以限制这些操作的落地范围，但决策逻辑存在于你的应用程序中。
零日漏洞：所有隔离模型都存在已知和未知的漏洞。微虚拟机隔离在当前生产中提供了最强的边界，但 VMM 漏洞仍然存在。纵深防御（结合多种控制措施而非信任单一边界）是比任何单一隔离模型更稳健的策略。
通过模型输出的社会工程：代理可能输出说服人工操作员采取不安全操作的结果。沙箱不会审计人工决策。
合规与法规风险：隔离控制解决技术风险。法规要求（GDPR、HIPAA、SOC 2、ISO 27001）涉及数据处理、保留、文档和审计要求，这些超出了沙箱在基础设施层面提供的范围。
代码执行沙箱的安全性最好视为一组需要评估和配置的控制措施，而不是通过选择产品就能获得的属性。上述评估问题适用于每个沙箱决策——包括如果你正在自行构建而非购买，你自己的基础设施。
常见问题
沙箱化 AI 代码执行环境与在服务器上直接运行代码相比安全性如何？
配置良好的沙箱显著减少了执行不可信代码的爆炸半径，相比直接在服务器上运行。它限制了文件系统访问、进程范围和网络访问。然而，差异取决于配置。一个开放出口、环境变量注入宽泛的容器，可能不如一个带有网络控制的加固服务器安全。隔离模型是起点，而非保证。
微虚拟机隔离是否意味着沙箱完全安全？
不。微虚拟机隔离（Firecracker、基于 KVM）提供了共享内核容器所不具备的强宿主机边界。但它无法控制出口、密钥、软件包安装或审计覆盖范围。一个开放出口且无日志收集的微虚拟机并非“完全安全”，即使隔离层很强。
AI 生成的代码能否逃逸沙箱？
这取决于隔离模型和配置。容器逃逸需要利用内核或配置错误；微虚拟机逃逸需要利用 VMM。两者虽可能但不常见。更实际的风险包括通过允许的网络路径进行数据外泄、从环境中读取密钥，或通过无限制的包管理器安装恶意软件包。
大多数 AI 代码沙箱中最大的安全风险是什么？
开放出站出口是最常被忽视的风险。许多沙箱默认允许无限制的出站互联网访问，因为这方便了需要安装软件包和调用 API 的代理。这为数据外泄、通过云元数据端点窃取凭证以及命令与控制通信创造了路径，而这些路径的存在与隔离边界的强度无关。
我应该使用托管沙箱还是自行构建？
托管沙箱处理微虚拟机或容器生命周期、宿主机容量和镜像管理的操作复杂性。自行构建让你对整个策略栈拥有更多控制权。无论哪种方式，相同的评估问题都适用：出口策略、密钥处理、日志覆盖范围、资源限制和审计导出。构建与购买决策独立于安全评估。
代理沙箱安全性与传统代码执行安全性有何不同？
传统代码执行安全性假设你大致知道将运行什么代码。AI 代理则不同：单次提示可能导致会话安装包、写入文件、运行 shell 命令、调用外部 API 并生成子进程，而无需开发人员对每一步明确批准。这使得审计覆盖范围更加重要（你无法预料每个操作），出口控制更加重要（代理可能到达你未预期的目标），密钥范围限定更加重要（代理可以访问其环境中的所有内容）。
