在允许生成的代码针对真实系统或数据运行之前，AI 智能体沙箱隔离审查应验证执行边界、文件系统暴露、进程和资源控制、网络和 DNS 策略、软件包获取行为、密钥处理、日志、制品捕获、重置语义、人工审批节点以及事件响应假设。
为什么 AI 智能体隔离审查很重要
传统的沙箱审查通常从一个问题开始：该系统能否在不暴露主机的情况下运行不受信任的代码？AI 智能体审查需要这个问题，但它还需要一个更广泛的清单，因为智能体所做的不仅仅是执行单个脚本。它们可能会克隆仓库、安装软件包、浏览网站、写入文件、调用 API、打开 GUI 会话、重试失败的命令，并将模型输出转化为 shell 操作。
这改变了风险模型。一个编码智能体的行为可能像一个拥有终端访问权限的初级工程师。一个数据分析智能体可能像一个上传文件、获取软件包并导出图表的工作簿用户。一个浏览器智能体可能像一个拥有 cookies、下载、截图和表单填充操作的用户。一个强化学习或评估智能体可能重复运行同一任务数千次，这使得小的出站、资源或日志缺口在规模上变得重要。
在将沙箱连接到敏感仓库、客户数据、内部 API、特权凭证或生产部署系统之前，请使用以下清单来审查边界。
执行边界安全
从将智能体工作负载与主机及其他租户分隔开的边界开始。审查应足够明确，以便安全工程师能够描述如果智能体运行恶意代码会发生什么失败。
检查：
- 使用了哪种隔离层：容器、microVM、完整 VM、类似 gVisor 的系统调用中介、Kubernetes 沙箱，还是其他模型？
- 每个沙箱是否拥有自己的内核边界，还是共享主机内核？
- CPU、内存、文件系统、进程表、网络栈和设备访问是否与其他工作负载分离？
- 沙箱能否访问容器运行时套接字、主机进程命名空间、主机路径、云元数据服务或特权设备？
- 浏览器会话、GUI 桌面、VNC 流和代码解释器如何放置在同一个边界内？
- 文档化的主机逃逸假设是什么：是遏制、风险降低，还是更强的保证？
避免将笼统的“安全沙箱”声明作为全部答案。要询问具体的隔离机制、边界内包含什么、外部是什么，以及哪些假设仍然需要补偿控制。
文件系统和挂载安全
智能体的文件系统值得单独审查，因为智能体通常会在正常工作中创建、编辑和泄露文件。风险不仅在于读写访问；还在于任务之间的意外遗留以及用户无意中共享的项目文件的隐式访问。
检查：
- 默认文件系统是空的、基于模板的，还是预加载了项目文件？
- 哪些路径是智能体可写的，哪些是只读的？
- 主机目录、仓库挂载、SSH 密钥、软件包缓存、浏览器配置文件或云配置文件是否被挂载到沙箱中？
- 智能体能否通过符号链接或绑定挂载遍历到非预期的路径？
- 文件访问是按沙箱、用户、项目还是组织进行范围限定的？
- 上传的文件是被删除、保留、快照，还是提供给后续会话使用？
- 生成的文件和差异在离开沙箱之前是否可审查？
对于编码智能体，最安全的模式通常是狭窄的项目工作区、显式的制品导出，以及不随意访问开发者主目录或共享凭据存储。
进程和资源控制
智能体可能会意外创建 fork 炸弹、挂起构建、填满磁盘、运行后台服务，或不断重试一个昂贵的命令。资源控制将这些失败转化为有界限的失败。
检查：
- 是否强制执行 CPU、内存、磁盘、文件描述符、进程数和运行时限制？
- 命令和会话是否有最大持续时间限制？
- 后台进程能否在命令完成后继续存在？
- 沙箱停止或重置时，子进程是否被终止？
- 智能体能否打开监听端口？如果可以，这些端口是否仅通过显式的预览机制暴露？
- 大量的 stdout/stderr 日志是否被截断、流式传输或存储？
- 配额失败是否对调用者可见，而不是静默重试？
对于生产环境中的智能体工作流，限制应作为 API 契约的一部分，而不仅仅是计费概念。安全团队应了解当智能体达到限制时会发生什么，以及失败是否留下部分状态。
网络和出站控制
网络策略是许多沙箱审查变得过于模糊的地方。一些智能体工作负载需要互联网访问；其他工作负载默认不应有互联网访问。正确的答案取决于沙箱是运行测试、浏览公共页面、获取软件包、调用内部 API，还是处理敏感数据。
检查：
- 出站互联网访问是否默认启用？
- 能否按沙箱、模板或项目禁用网络访问？
- 是否可以对域名、IP 范围、端口或协议使用出站允许列表？
- 对云元数据端点的访问是否被阻止？
- 沙箱能否访问私有 VPC、内部服务、数据库或部署系统？
- 浏览器流量、CLI 流量、包管理器流量和直接套接字连接是否受同一策略约束？
- 出站请求是否记录时间戳、目标、进程或命令上下文以及响应状态？
将智能体的出站流量视为构建系统的出站流量。如果智能体可以安装软件包、上传制品、调用 webhook 或浏览任意网站，审查应涵盖恶意代码和提示注入驱动的行为。
DNS 和软件包访问风险
DNS 和包管理器很容易被忽视，因为它们感觉像基础设施管道。对于智能体来说，它们是执行面的一部分。生成的脚本可以将数据编码到 DNS 查询中，获取一个拼写错误的软件包，或从一个从未被审查的 URL 拉取脚本。
检查：
- DNS 流量是否遵循与 HTTP 和 HTTPS 相同的出站策略？
- DNS 查询是否被记录、过滤或强制通过受控的解析器？
- 包管理器能否默认访问公共注册表？
- 软件包注册表是否被允许列表、代理、缓存或固定？
- 已安装的软件包名称、版本、URL、哈希和锁文件更改是否被捕获？
- 智能体能否运行安装脚本、postinstall 钩子或任意的软件包构建步骤？
- 在将新依赖项持久化到模板或生产工作流之前，是否有审查关卡？
如果需要软件包访问，建议使用固定版本、锁文件、注册表允许列表，以及让审查者能够重建已下载和已执行内容的日志。
密钥处理
密钥通常是沙箱边界变得无关的最快方式。如果智能体看到一个宽泛的令牌，它可以在不逃逸主机的情况下泄露数据。
检查：
- 密钥是否仅在任务明确需要时才注入？
- 密钥是否按沙箱、任务、仓库、环境和生命周期进行范围限定？
- 密钥能否从环境变量、文件、shell 历史、进程列表、日志、截图或浏览器存储中读取？
- 日志和制品在存储或导出之前是否进行脱敏处理？
- 是否使用短期令牌代替长期凭证？
- 智能体能否从主机访问用户级别的 SSH 密钥、Git 凭据、云凭据、浏览器 cookies 或 API 密钥？
- 密钥访问在审计日志中是否可见？
一个实用的规则：如果人类不会将凭据粘贴到不受信任的构建作业中，那么在没有更窄范围和更强日志记录的情况下，也不要将其交给自主智能体。
日志和审计追踪
安全团队需要的不仅仅是成功或失败。他们需要知道运行了什么代码、更改了什么文件、发生了什么网络调用以及产生了什么输出。
检查：
- 命令调用是否记录参数、工作目录、退出代码、开始时间和持续时间？
- 文件读取、写入、删除、上传、下载和权限更改是否被记录？
- 软件包安装和外部获取是否被记录？
- 浏览器操作、截图、下载和表单提交是否在相关情况下被捕获？
- API 调用、工具调用和模型到工具的转换是否关联到同一会话？
- 日志是否对沙箱内部具有防篡改能力？
- 保留期是多长，谁可以访问日志？
对于受监管或企业工作流，审计追踪应支持调试和事件后重建。部分终端转录通常是不够的。
制品捕获和审查
智能体创建有用的输出：差异、测试结果、报告、截图、生成的文件、预览 URL 和数据集。制品处理应使这些输出可审查，而无需暴露比所需更多的状态。
检查：
- 哪些制品是自动导出的，哪些需要显式选择？
- 审查者能否在生成的文件被提交、上传或发送到其他服务之前检查它们？
- 制品是否被扫描以查找密钥、恶意软件、不安全的文件类型或意外大小？
- 浏览器下载是否与源代码差异和测试输出分开存储？
- 制品能否链接回产生它们的确切命令、智能体步骤和沙箱会话？
- 沙箱删除后制品是否保留，它们能否被清除？
目标是保留有用的证据，同时避免通过日志、截图、归档或生成的包创建第二个数据泄露通道。
生命周期和重置控制
智能体会话可以是短生命周期的、长期运行的、暂停的、恢复的、快照的或从模板克隆的。每种生命周期模式都会改变边界。
检查：
- 每个沙箱是全新创建的、从状态恢复的，还是从模板克隆的？
- 哪些数据在暂停、恢复、快照、模板创建和删除后仍然存在？
- 临时文件、软件包缓存、shell 历史、浏览器 cookies 和本地数据库在重置时是否被清除？
- 受损的会话是否会污染可重用的模板？
- 是否有最大会话生命周期？
- 停止的沙箱是否真正终止，还是后台任务可以继续？
- 同一任务能否从干净环境重现？
对于评估和强化学习工作负载，可重置性也很重要。如果每次试验从略有不同的状态开始，安全发现和模型行为将更难信任。
人工审批控制
人工审批不仅仅是一个用户体验功能。它是针对跨越信任边界的操作的控制平面。
检查：
- 哪些操作可以自主运行，哪些需要批准？
- 审批提示是否足够具体，以显示命令、文件、目的地、凭据范围和预期效果？
- 策略是否要求对软件包安装、外部网络访问、仓库写入、部署命令或密钥访问进行审批？
- 审批是否记录用户、时间戳、操作和产生的命令？
- 审批是否可以具有时间限制和任务限制，而不是授予广泛的未来权限？
- 是否有紧急通道，并且是否被审计？
对不可逆或高影响的操作使用人工审批：删除文件、写入生产分支、调用部署 API、访问客户数据以及更改沙箱模板。
事件响应假设
没有沙箱审查是完整的，除非询问当边界失败或工作流出现意外行为时会发生什么。这对于智能体系统尤其重要，因为风险行为可能由模型输出、提示注入、依赖项受损或普通软件错误引起。
检查：
- 当沙箱被怀疑泄露数据或运行恶意代码时，谁负责分类？
- 沙箱能否按项目或组织被终止、隔离或阻止？
- 网络出站能否快速禁用？
- 日志和制品是否保留以供调查？
- 受影响的模板、软件包缓存和快照是否失效？
- 凭据是否自动轮换或通过文档化的运行手册轮换？
- 沙箱容器问题与智能体策略问题之间是否有明确的区分？
审查应以书面的威胁模型和简短的事件响应手册结束。即使最终决定是“仅批准用于非敏感工作负载”，该边界也是有用的。
Novita Agent Sandbox 如何适用
Novita Agent Sandbox 专为 AI 生成的代码、浏览器工作流、计算机使用、评估、强化学习环境和长期运行任务而设计。产品页面描述了隔离的沙箱、亚秒级启动、持久会话、基于 VNC 的实时会话查看、按使用量计费、模板和隔离的文件系统支持。Novita Agent Sandbox 快速入门 展示了基于 SDK 的沙箱创建、命令执行、文件列表和沙箱关闭。
这些功能可以支持本清单中的许多工作流，但评估标准和产品声明应保持分离。当您的团队审查 Novita Agent Sandbox 或任何其他智能体运行时，请将您计划使用的实际配置与上述控制措施进行对照：边界、文件、进程限制、网络、DNS、软件包获取、密钥、日志、制品、生命周期、审批和事件响应。
对于已经使用 Novita AI 模型 API 的工程团队，将模型推理与沙箱执行相结合可以减少智能体工作负载的平台扩散。对于安全敏感的生产环境，在将沙箱连接到私有仓库、敏感数据集、内部服务或部署凭据之前，仍然需要运行特定于工作负载的审查。
结论
只有在审查能够清晰回答三个问题后，才批准 AI 智能体沙箱：什么被隔离了，什么仍然可以离开边界，以及如果出现问题，还有哪些证据保留。如果这些答案模糊，将沙箱仅限于非敏感工作负载，直到缺失的控制措施被记录和测试。
常见问题
安全团队在 AI 智能体沙箱审查中应该首先验证什么？
从执行边界、文件系统暴露和网络默认值开始。这三个控制措施决定了恶意代码是否能在您进入工作流特定的细节（如审批和制品导出）之前到达主机、敏感文件或外部目标。
仅使用容器的沙箱对于自主编码智能体是否足够？
这取决于工作负载及其可以访问的数据。对于具有严格挂载、严格出站策略、短期凭证和强大日志记录的低敏感度任务，容器可能是可接受的，但安全团队应基于文档化的控制措施做出决定，而不是仅仅基于“容器”这个词。
为什么 DNS 和软件包访问需要与一般出站流量分开审查？
因为智能体通常在正常操作中安装依赖项和解析外部主机。如果 DNS 查询和软件包获取未被记录、过滤或限制，它们可能同时成为数据泄露路径和供应链风险。
推荐文章：
