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