企业如何评估 AI Agent 沙箱：一份从隔离到审计的安全检查清单

本文根据 Northflank 文章《AI-agent sandbox security checklist: What enterprises should evaluate》整理。原文由 Deborah Emeni 撰写，发表于 2026 年 9 月 3 日。本文保留其企业评估框架，并补充面向安全团队的落地检查方式。

一句话结论

企业评估 AI Agent 沙箱时，不能只接受“已经隔离”这一句产品描述；真正需要验证的是：沙箱能否把恶意代码、提示注入、恶意依赖和工具响应的影响限制在预期边界内，以及身份、凭证、网络、数据、资源、生命周期和审计控制是否能独立于 Agent 生效。

Northflank 原文的重点不是推荐某一种沙箱技术，而是要求企业把沙箱当成一条完整的执行边界来审查。微虚拟机或 gVisor 可以增强运行时隔离，但不能替代授权、网络策略、密钥管理、审计和上线前的对抗测试。

为什么 Agent 沙箱不能只看“容器化”

AI Agent 可能执行代码、安装依赖、读取文件、访问 API、调用工具，甚至修改基础设施。只要 Agent 能接触到不可信输入或不受控的工具响应，攻击者就可能通过直接或间接提示注入，诱导它执行超出原始任务的操作。

需要纳入威胁模型的不可信对象包括：

• Agent 生成的命令和代码。
• 用户上传的文件。
• 外部代码仓库和 Pull Request。
• 安装脚本、软件包和构建依赖。
• 网页、搜索结果和检索内容。
• 工具返回值和第三方 API 响应。
• Agent 的持久化记忆、缓存和工作目录。

需要保护的对象则包括宿主机和内核、编排服务、云凭证、挂载文件、内部 API、其他租户、控制平面、生产数据和审计系统。

因此，“Agent 能否运行代码”不是唯一问题，更关键的是：一旦 Agent 或其依赖被操纵，代码还能触达哪些系统？

十项企业级检查清单

1. 明确威胁模型和信任边界

在选择沙箱前，先画出数据流和信任边界，而不是先选择某个产品。

至少应记录：

红队应当能够根据这份图和假设，测试沙箱内代码可以到达什么位置，以及一个泄露的平台凭证可以改变什么。

2. 让隔离强度匹配工作负载

隔离边界应当由代码信任程度、租户数量、可访问数据和潜在影响决定。

评估供应商时，不要只问“是不是 microVM”。还要问：

• Guest 是否拥有独立内核？
• 宿主设备和文件系统暴露了什么？
• 默认移除了哪些 Linux capabilities 和特权？
• 宿主机、运行时和基础镜像如何打补丁？
• 已运行的沙箱是否必须重启才能获得修复？
• 如何验证容器逃逸、设备访问和跨租户访问？

Northflank 文档将其 Sandboxes 描述为微虚拟机支持的容器服务，并提供 gVisor 等运行时隔离选项；具体可用运行时取决于提供商和区域，企业不应把文档中的能力直接视为所有部署位置的默认配置。

3. 分离人、Agent 和工作负载身份

Agent 不应继承开发者登录会话，也不应使用共享管理员 Token。一次执行至少应当能够追溯到：

• 发起人。
• Agent 或工作负载身份。
• 策略版本。
• 目标资源和租户。
• 请求参数。
• 授权时间窗口。
• 最终执行结果。

从测试环境进入生产环境时，应重新做一次授权决策，而不是沿用测试阶段的授权上下文。

如果使用平台 API，应为自动化程序创建来自最小 RBAC 角色的 API Token，并设置过期时间。Northflank 文档明确说明 API Token 继承其 RBAC 角色权限，Token 密文只在创建时显示一次，不能提交到代码仓库。

4. 将密钥限制在单个任务

给沙箱注入密钥，不等于给 Agent 授予业务权限。密钥应当同时满足：

• 只注入当前任务需要的值。
• 绑定到指定工作负载或服务。
• 具备明确的撤销时间窗口。
• 尽可能是短时、窄权限和受众绑定的凭证。
• 不出现在命令行、日志、错误消息和模型上下文中。
• 任务结束后能够撤销或失效。

安全团队需要分别审查“谁可以把密钥注入沙箱”和“持有该密钥的程序可以执行什么业务操作”。这两者不能用同一个权限开关代替。

5. 默认拒绝网络访问

推荐从无公网入站、默认拒绝出站开始，只放行任务明确需要的目的地。

网络检查应覆盖：

• 入站端口是否默认关闭。
• 出站域名是否使用 allowlist。
• DNS 查询是否可被滥用为隐蔽通道。
• 是否能访问云实例元数据服务。
• 是否能访问内部控制平面、数据库和管理 API。
• 是否可以直接向任意公网地址上传文件。
• 不同租户和不同任务之间是否能互相通信。

如果域名级控制无法验证请求内容，应在出口增加网关，对目标、方法、参数和载荷进行校验。Northflank 的 BYOC 网络策略文档提醒：如果某个方向没有配置规则，流量可能仍然被允许，因此“配置了网络策略”不等于“已经默认拒绝”。

6. 把文件、记忆、缓存和持久化存储单独治理

存储状态不是计算资源的附属品，而是另一条安全边界。

应当分别回答：

• Agent 能读取工作目录之外的哪些文件？
• 不同任务是否共享缓存？
• 暂停、恢复和重启后哪些数据仍然存在？
• 持久化卷是否跨租户复用？
• 删除沙箱时是否同时删除快照、卷和临时文件？
• 是否有数据保留期限和人工清理流程？
• 任务输出是否可能把密钥或内部数据带出沙箱？

短任务优先使用临时根文件系统。只有确实需要跨重启保存工作区时，才启用持久化卷，并单独设计访问授权、加密、备份和销毁策略。

7. 控制镜像、依赖和工具供应链

沙箱只能限制运行边界，不能自动证明镜像、软件包和工具是安全的。以下对象都应纳入供应链审查：

• 基础镜像和镜像标签。
• 启动脚本和初始化组件。
• Agent 安装的 npm、PyPI 或系统软件包。
• 外部仓库中的构建脚本。
• MCP Server、插件和工具适配器。
• 沙箱平台自身的运行时和宿主组件。

上线前至少应测试恶意软件包、依赖混淆、被替换的镜像标签和恶意工具响应。镜像扫描是必要控制，但扫描结果不能证明运行时行为安全；还需要固定来源、锁定版本、验证签名或摘要，并保留构建和部署证据。

8. 限制资源并验证生命周期清理

没有资源限制的 Agent，即使没有逃逸，也可能通过死循环、并发任务或超大输出造成拒绝服务和成本失控。

应当为每次任务设置：

• CPU 和内存上限。
• GPU 配额（如适用）。
• 磁盘和输出大小上限。
• 运行时长和空闲超时。
• 子进程和并发数限制。
• API 调用次数和费用上限。
• 创建、暂停、恢复和删除权限。

生命周期必须可追踪：创建时记录发起身份和策略版本，运行时记录状态变化，结束时确认资源释放，异常终止时执行兜底清理。不要只观察“页面上已经删除”，还要核对底层卷、快照、临时凭证和网络资源是否一并处理。

9. 建立平台审计和 Agent 遥测

审计日志的目标是重建一次运行“为什么被允许、做了什么、影响了什么、如何结束”，而不是收集模型的私密思维过程。

建议分成两层：

两层日志需要使用共同的会话 ID 或运行 ID 关联。Northflank 的审计日志文档说明，其平台事件包含事件类型、触发用户、事件来源、时间戳、父事件、子事件和受影响资源；应用仍需要自行记录 Agent 的模型、工具和业务数据活动。

日志系统本身也要防止被 Agent 修改或删除，并限制敏感数据落盘。应优先记录可审计的操作事实，而不是把完整提示词、客户数据和模型内部推理过程无差别写入日志。

10. 用对抗测试证明隔离有效

安全审批应建立在失败行为已经被测试的基础上，而不是建立在供应商的“安全”标签上。

建议至少覆盖以下测试：

测试时要验证控制是否独立于 Agent 和 Agent 能够修改的系统。否则，攻击者一旦控制了应用层，就可能同时修改安全策略、日志或审批状态。

哪些回答应当阻止上线

以下问题如果无法回答，至少应阻止生产授权，直到有补偿控制和明确负责人：

• 沙箱是否与宿主机、其他租户或控制平面共享关键安全边界？
• Agent 能否访问未列入任务范围的文件、网络和 API？
• 凭证是否长期存在、权限过大或无法撤销？
• 网络是否默认允许出站？
• 任务结束后是否能证明数据、凭证和运行资源已经清理？
• 是否可以把平台审计和应用 Agent 行为关联起来？
• 是否做过提示注入、跨租户、外传、权限升级和逃逸测试？
• 发生失败时，是否有独立于 Agent 的停止、隔离和回滚机制？

“文档没有写清楚”本身未必等于漏洞，但“不承认边界、不提供证据、无法复现控制”应当被视为上线风险。补偿措施必须写明负责人、有效期、验证方式和退出条件。

对企业落地的建议顺序

不要一开始就追求最高规格的沙箱平台，建议按以下顺序建立最小可用控制面：

1. 先分类任务：区分可信代码、生成代码、用户代码、多租户代码和生产操作。
2. 先收窄权限：为人、Agent、任务和工作负载分别建身份，不共享管理员 Token。
3. 先隔离运行时：对不可信代码采用独立内核或更强隔离边界。
4. 先关闭默认网络：只放行任务需要的入口、出口和内部服务。
5. 先使用临时存储：持久化必须有明确业务理由和独立生命周期策略。
6. 再接入 AI 模型：先让确定性授权和网络策略生效，再启用更高自治能力。
7. 最后扩大生产权限：以对抗测试、审计证据和故障演练结果作为放权条件。

结语

AI Agent 沙箱的核心价值不是让 Agent“可以运行代码”，而是让企业能够在可控范围内允许它运行不可信代码。判断一个方案是否适合生产，不能只比较容器、微虚拟机或 gVisor 的名词，而要检查完整的执行边界：谁发起、拿到什么凭证、能访问什么网络和数据、消耗多少资源、结束后是否清理、操作能否追溯，以及在被提示注入和恶意依赖操纵后是否仍然成立。

对于安全团队来说，最有价值的交付物不是一句“已隔离”，而是一份可复核的边界说明、授权矩阵、网络策略、数据保留方案、审计证据和对抗测试报告。

参考资料

• Northflank：AI-agent sandbox security checklist: What enterprises should evaluate（2026-09-03）
• Northflank Sandboxes 文档
• Northflank API Token 与 RBAC 文档
• Northflank Audit Logs 文档
• OWASP GenAI：LLM06:2025 Excessive Agency

来源字段：2026-09-03｜Northflank，Deborah Emeni｜https://northflank.com/blog/ai-agent-sandbox-security-checklist｜企业 AI Agent 沙箱安全检查清单，覆盖隔离、身份、凭证、网络、数据、供应链、资源、审计和对抗测试｜适合作为 Agent 代码执行、云端沙箱和多租户平台上线前的安全评估框架。