当沙箱中的代码能够解析攻击者控制的域名或利用 DNS 作为出站数据通道时，DNS 数据外泄风险就显得至关重要。因此，在信任某个 AI 智能体沙箱处理敏感工作流之前，团队应评估其 DNS 策略、日志记录、包获取路径以及事件证据。
为什么 DNS 在沙箱威胁模型中如此重要
AI 智能体沙箱旨在提供实用的自主能力。一个编程智能体可以在无需人工批准每条命令的情况下，运行测试、安装包、调用 API、启动浏览器、检查文件并生成制品。正是这种灵活性决定了网络行为需要单独审查，与 CPU、内存、文件系统和进程隔离分开。
DNS 往往比 HTTP 出口更少受到关注，因为它看起来更像基础设施的管道。应用程序需要通过名称解析来访问 API、注册中心、网页和更新端点。但 DNS 仍然是出站通信。一个能够解析任意域名的沙箱可能通过查询名称泄露信息、联系攻击者控制的基础设施，或者如果 DNS 流量没有像网络请求一样被仔细记录，就会造成盲区。
这并不是为 AI 智能体凭空捏造的理论类别。MITRE ATT&CK 将 DNS 记录为一种应用层协议，攻击者可用于命令与控制通信；同时，它还单独记录了通过替代协议进行的数据外泄——当数据通过非主应用协议的通道离开时。对于沙箱评估者来说，经验教训很直接：不要仅仅因为 DNS 不是 HTTP POST 就将其视为无害。
对于 AI 智能体，风险通常来自一系列微小权限的连锁反应，而非一个明显的错误：
| 沙箱能力 | 团队允许的原因 | 与 DNS 相关的问题 |
|---|---|---|
| 包安装 | 允许智能体安装缺失的依赖 | 允许哪些注册中心和解析路径？ |
| 网络访问 | 允许浏览器智能体获取公开上下文 | 代码可以解析任意域名还是仅限批准的域名？ |
| API 调用 | 允许智能体与应用后端集成 | 内部域名和元数据端点是否被阻止？ |
| 构建工具 | 允许编程智能体运行逼真的测试 | 安装后脚本是否会触发意外的 DNS 查询？ |
| 长时运行会话 | 允许智能体继续多步骤任务 | DNS 日志是否会保留整个会话生命周期？ |
目标不是禁止所有网络调用。许多智能体工作负载需要受控的网络访问。目标是了解哪些路径存在，哪些路径被阻止，以及在任务出现异常行为时你拥有哪些证据。
DNS 解析在智能体工作流中的出现点
安全审查通常会问沙箱是否有互联网访问。这个问题过于宽泛。更好的审查从映射代码、工具、包管理器或浏览器可能触发名称解析的每个位置开始。
常见的 DNS 路径包括：
- 来自 Python、JavaScript、Shell 脚本、SDK 和测试套件的直接代码请求。
- 加载页面、子资源、字体、图像、分析脚本和重定向的浏览器自动化。
- 诸如 npm、pip、uv、pnpm、apt、cargo 或特定语言的插件安装程序等包管理器。
- 获取二进制文件、模板、浏览器驱动、模型文件或测试夹具的构建工具。
- 调用第三方 API 或 Webhook 端点的智能体工具。
- 在可见的智能体步骤返回后继续运行的后台任务。
该映射应包括有意的和附带的流量。开发者可能只要求智能体运行一个单元测试，但测试命令可能安装一个包，包管理器可能解析一个注册中心域名，而生命周期脚本可能联系一个不同的主机。浏览器任务可能限定于一个公共网站，而嵌入的资源会解析许多额外的域名。
对于沙箱提供商来说，最有力的回答不仅仅是“网络访问可用”或“网络访问已隔离”。有用的回答需要解释解析路径：
- 沙箱 DNS 使用提供商控制的解析器、客户控制的解析器、VPC 解析器还是公共解析器？
- 客户是否可以限制域名、IP 范围、端口或协议？
- DNS 请求是按沙箱、按会话、按命令记录，还是仅在聚合网络层记录？
- 被拒绝的查询是否也会记录，还是只记录允许的查询？
- 客户能否将包获取 DNS 与运行时 DNS 分开？
如果这些细节不可用，请将其视为待评估项目，而非沙箱不安全的证据。实际风险取决于工作负载的敏感性、沙箱内可用的机密、出站策略以及取证证据的质量。
如何评估出站策略
出站策略是决定 DNS 是常规管道还是未经审查的逃逸路径的控制面。一个成熟的策略应回答三个问题：允许什么、为什么允许、以及如何批准例外情况。
从默认态势开始。用于不受信任的 AI 生成代码的沙箱不应继承与开发者笔记本电脑相同的广泛网络访问权限。如果默认是开放出口，请问产品是否支持为高风险工作负载缩小访问范围。如果默认是限制出口，请问开发者如何为特定任务启用所需的准确域名。
然后将 DNS 策略与 HTTP 策略分开。一些系统执行 HTTP 允许列表，但保留广泛的名称解析。这可能会导致不匹配：对未经批准主机的请求可能在 HTTP 层失败，但 DNS 查询仍然离开环境，并且可能仍然在查询的名称中携带元数据。更严格的设计会将解析尝试和连接尝试一起评估。
对于安全审查，使用如下策略矩阵：
| 评估领域 | 要问的问题 | 更有力的证据 |
|---|---|---|
| 默认出口 | 出站网络访问是开放的、拒绝的还是按模板限定的？ | 书面默认策略加上沙箱级测试结果 |
| DNS 解析器路径 | 哪个解析器处理沙箱 DNS？ | 架构图或配置证明 |
| 域名允许列表 | 团队能否仅允许批准的注册中心和 API？ | 配置示例和拒绝日志示例 |
| IP 和私有网络阻止 | 默认是否阻止内部范围和元数据服务？ | 记录的拒绝规则和测试证据 |
| 协议控制 | DNS、HTTP、HTTPS 和原始套接字是否分别控制？ | 策略模型，不仅仅是营销用语 |
| 异常工作流 | 谁可以添加域名或放宽策略？ | 基于角色的审批和审计记录 |
对于大多数团队而言，第一个实际目标并非完美的零出口环境，而是有文档记录的最小出口配置文件：批准的包注册中心、批准的 API 域名、除非明确路由否则无法访问内部网络、以及允许和拒绝尝试的日志。
包获取与依赖驱动的 DNS
包安装是最容易被低估沙箱出口能力的途径之一。智能体生成的代码经常因缺少依赖而失败，最快的开发者体验就是让智能体安装所需内容。这种便利性带来了第二个供应链问题：包名、注册中心重定向、安装脚本和二进制下载可能触发原始提示从未提及的 DNS 和网络活动。
OWASP 的 LLM 应用指南指出了过度代理和供应链暴露的风险。在智能体沙箱中，这些风险在包安装处交汇。模型可能被允许选择命令。命令可能调用包管理器。包管理器可能从注册中心获取代码。获取的包可能运行安装钩子。每一步都可能产生 DNS 查询和出站连接。
防御性评估应侧重于治理，而非利用机制：
- 对于可重复的智能体任务，优先使用固定依赖文件。
- 对于常见生态系统，使用批准的注册中心或拉取缓存。
- 记录包名称、版本、注册中心 URL、解析的域名和制品哈希（如果可行）。
- 将包安装权限与常规运行时互联网访问分开。
- 敏感工作区中，安装允许列表之外的包需要获得批准。
- 考虑为常见栈使用预构建的沙箱模板，这样智能体在每次运行时无需广泛的网络访问。
重要的区别在于，“包获取”并非单一控制。它包括 DNS 解析、注册中心认证、制品下载、安装时代码执行和缓存行为。一次好的沙箱审查需要评估整个路径。
机密和数据暴露假设
只有在有值得泄露的内容时，DNS 数据外泄才有意义。这使得机密放置和数据范围界定成为 DNS 审查的一部分。
除非另有证明，否则 AI 智能体沙箱应被视为不受信任的构建工作器。不要仅仅因为沙箱与主机隔离，就将长期存在的生产凭证、广泛的云令牌、客户数据或内部源代码放入沙箱。隔离减少了爆炸半径，但并不能使每条命令都安全。
在设计更高风险的工作流时，请使用以下假设：
- 智能体执行的代码可读的任何文件都可能被包含在日志、输出、网络请求或错误消息中。
- 进程可见的任何环境变量都可能被该进程复制。
- 沙箱允许的任何出站通道都应接受同等的数据丢失审查，包括 DNS。
- 浏览器或文档工作流中任何提示注入的指令都可能试图影响工具使用。
- 任何长时间运行的会话都会增加生命周期日志和令牌过期的价值。
实际控制包括短期凭证、最小权限 API 密钥、限定范围的服务账户、按任务分配的机密、已清理的日志，以及将公共数据研究任务与敏感代码执行任务明确分开。
日志、审计追踪和事件证据
只有团队能够验证它们时，DNS 控制才有用。当沙箱任务可疑时，安全团队需要快速获得证据：运行了什么、解析了什么、连接了什么、哪些文件发生了更改、返回了什么输出。
至少，请问平台是否能为特定沙箱会话重建以下事件：
- 沙箱创建时间、模板、资源配置和所有者。
- 智能体或用户执行的命令。
- 当产品暴露文件操作时，读取、写入、上传或下载的文件。
- 包安装和注册中心获取。
- DNS 查询，包括时间戳、查询名称、结果以及沙箱/会话标识符。
- 出站连接尝试，包括目标主机、IP、端口、协议、允许/拒绝结果以及（如果可用）数据量。
- 工具调用、浏览器导航事件和后台进程。
- 机密注入事件，但不在日志中暴露机密值。
- 会话终止、暂停、恢复、快照和清理事件。
不仅要求成功流量日志。被拒绝的事件通常对于评估策略是否有效更有用。如果沙箱尝试解析未经批准的域名，而策略阻止了它，那么那次被拒绝的查询就是区分功能控制与静默失败的证据。
保留期限也很重要。七天的日志窗口可能足以进行调试，但对于事件响应来说可能太短。处理受监管或客户敏感工作负载的团队应使沙箱遥测保留与其更广泛的安全日志记录策略保持一致。
Novita Agent Sandbox 评估说明
Novita Agent Sandbox 专为需要隔离代码执行、浏览器自动化、计算机使用风格任务、长时间运行会话以及评估或强化学习工作负载的 AI 智能体工作流而设计。Novita Agent Sandbox 概述 是了解当前产品行为的正确起点，而 Agent Sandbox 产品页面 描述了更广泛的平台适配情况。
在评估 Novita 或任何其他沙箱提供商是否适合 DNS 敏感工作负载时，请区分两种类型的陈述：
- 产品适配性：沙箱是否支持您需要的智能体工作流，例如代码执行、浏览器自动化或长时间运行的任务。
- 安全控制证据：具体的 DNS、出口、包获取、机密和日志控制是否满足您的内部策略。
这种区分可以防止过度声称。一个沙箱可能非常适合智能体执行，但仍然需要客户针对 DNS 策略、解析器路径、允许列表、审计保留和事件工作流进行具体审查。在批准敏感工作负载之前，安全团队应就这些控制细节向提供商索取当前文档或产品确认。
对于已经在使用 Novita AI 模型的团队来说，平台适配性在于可以将模型 API 和智能体执行基础设施一起评估。这可以减少操作分散，但并不能消除威胁模型的需求。将沙箱视为受控执行环境，定义每个智能体类别需要哪些网络访问权限，并验证控制证据是否与放置在内部的数据风险相匹配。
安全检查清单
在批准可能接触敏感代码、凭证、客户数据或内部系统的 AI 智能体沙箱工作负载之前，请使用此清单。
| 审查问题 | 为何重要 |
|---|---|
| 默认情况下沙箱可以解析什么？ | 即使在 HTTP 被阻止的情况下，DNS 也可能成为出站信号。 |
| DNS 是否可以按域名、模板、工作区或 VPC 策略进行限制？ | 敏感工作流需要比公共研究任务更严格的默认设置。 |
| DNS 查询是否按沙箱会话记录？ | 事件响应需要归因，而不仅仅是聚合解析器指标。 |
| 被拒绝的 DNS 和连接尝试是否也会记录？ | 被拒绝的事件证明策略阻止了意外行为。 |
| 包注册中心是否被列入允许列表或代理？ | 包管理器可能触发依赖驱动的 DNS 和下载。 |
| 包安装是否能够与运行时网络访问分开？ | 构建时和运行时的风险不同。 |
| 内部 IP 范围和元数据端点是否被阻止？ | 智能体不应偶然发现或联系基础设施控制平面。 |
| 机密是如何注入、限定范围、轮换和清理的？ | 如果长期存在的机密可供沙箱代码使用，DNS 审查就不完整。 |
| 浏览器子资源在日志中是否可见？ | 浏览器智能体可能解析比顶级 URL 更多的域名。 |
| 在暂停、恢复、快照或清理之后，有哪些证据可用？ | 长时间运行的会话需要知晓生命周期的遥测。 |
| 谁可以放宽出口策略？ | 例外变更应是可审计的。 |
| 可疑会话如何保存？ | 清理不应抹去唯一有用的事件证据。 |
如果几个答案未知，请将工作负载保留在沙箱之外，直到提供商或内部平台团队能够记录控制路径。如果工作负载仅处理公共数据且不使用机密，相同的差距在早期原型设计中可能是可以接受的，但在生产使用之前仍应进行追踪。
结论
对于生产环境的智能体沙箱，请将 DNS 视为出口的一部分进行审查，而不是一个脚注。最小的防御性设置包括限定的出站策略、明确的包获取治理、短期机密、每会话的 DNS 和连接日志，以及经过测试的用于保存证据的事件工作流。
仅当数据非敏感且智能体没有有意义的机密时，才将广泛的网络访问用于低风险原型。对于敏感代码库、客户数据、内部 API 或受监管的工作流，要求最小出口配置文件和当前提供商的证据，然后再授予智能体自主执行权限。
常见问题
如果沙箱阻止了 HTTP，DNS 数据外泄仍然相关吗？
是的。HTTP 控制和 DNS 控制是不同层面。沙箱可能阻止出站 Web 请求，同时仍然允许 DNS 查询。安全团队应同时验证解析策略和连接策略。
AI 智能体沙箱是否应该没有互联网访问？
不一定。许多有用的智能体任务需要包注册中心、公共文档、API 或浏览器访问。更安全的目标是最小化、可解释的出站：允许任务所需内容，拒绝不需要的内容，并记录允许和拒绝的活动。
包安装是否等同于常规网络访问？
不。包安装应拥有单独的策略，因为它们涉及注册中心、依赖解析、制品下载以及有时安装时的脚本。团队可以通过批准的缓存允许包获取，同时拒绝任意运行时出口。
对于 DNS 风险，哪些日志最重要？
最有用的日志将 DNS 查询连接到特定的沙箱、命令、时间、用户或智能体工作流以及策略决策。被拒绝的查询日志尤其重要，因为它们显示了控制是否真正起作用。
沙箱提供商能保证没有数据外泄吗？
对绝对保证要谨慎。提供商可以提供隔离、网络控制、日志记录和配置选项，但最终风险取决于工作负载设计、机密、数据放置、出站策略和运营监控。
