AI 智能体沙箱是安全自主性的控制平面

当智能体的行动速度超过你的防护栏时，麻烦就开始了。浏览器自动化、shell 命令、文件访问和代码执行都很有用，直到智能体获得对不该触碰的系统的广泛访问权限。AI 智能体沙箱让自主操作变得可用，而不会将其变成无限制的系统访问。沙箱为智能体可以触及、更改和泄露的内容设定了硬性边界。

目录

• AI 智能体沙箱是安全自主性的控制平面

• AI 智能体沙箱关键要点

• 威胁模型优先：在选择容器或临时 VM 之前映射智能体操作 将隔离与工作负载匹配 实用选择规则

• 针对每个执行面的 AI 智能体沙箱：浏览器、shell、文件访问和代码执行 浏览器自动化 Shell 命令 文件访问 代码执行

• AI 智能体沙箱需要网络出口控制、文件系统隔离和硬性资源限制 默认拒绝网络出口优先 文件系统隔离必须简单且严格 硬性资源限制阻止昂贵的故障

• 设置审批边界、保护凭据，并为沙箱逃逸尝试做好规划 将人类置于风险边缘 将机密排除在工作区之外 假设逃逸尝试会发生

• 生产环境中的 AI 智能体沙箱：审计日志与决策框架

• 常见问题 什么是实际意义上的 AI 智能体沙箱？AI 智能体沙箱与普通应用安全有何不同？为什么某些智能体任务应使用临时 VM 而非容器？当智能体需要调用外部服务时，如何保护凭据？生产智能体的审计日志除了基本命令历史外还应包含什么？

实际选择很简单，即使实现并不简单：使用容器以获得速度和吞吐量；当任务涉及不受信任的代码或恶意网页内容时，使用临时 VM 或 microVM 以获得更强的隔离。然后通过出口控制、只读文件系统、cgroups、seccomp、AppArmor 或 SELinux、审批门和审计日志来分层构建安全的 AI 智能体运行时。

在 Imversion Technologies Pvt Ltd，我们将 AI 智能体沙箱视为控制平面，而不仅仅是包装器。AI 智能体沙箱化关乎爆炸半径。一个快速的智能体执行沙箱如果缺少元数据阻断、凭据隔离或命令和文件路径日志记录，仍然是不安全的。用户体验在这里也很重要——审批提示和日志必须足够清晰，以便人类快速采取行动。

AI 智能体沙箱关键要点

• 从一开始就将智能体视为不受信任的操作者。对于实际的 AI 智能体沙箱化，默认采用最小权限，阻断元数据端点，通过代理限制网络出口，并保持文件系统只读，除非任务确实需要写入。

• 使用分层隔离，而非对所有情况采用单一策略。低风险解析或测试运行适合容器中的加固智能体执行沙箱；在不受信任的站点上进行浏览器自动化和任意代码应放在临时 VM 或 microVM 中。

• 运行时隔离还不够。审批门、短期凭据和机密范围界定与 AI 智能体沙箱同样重要。

• 记录每个操作——命令、文件路径、网络目标、审批事件和产物哈希。清晰的审计追踪更易于维护和信任。

威胁模型优先：在选择容器或临时 VM 之前映射智能体操作

团队从基础设施入手时容易犯错。Docker（容器化平台）、Firecracker 或 gVisor 可能是最终选择，但它们不应是第一个讨论的话题。正确的 AI 智能体沙箱源于任务在智能体行为不当、被提示注入或接触恶意输入时可能造成的损害。

浏览器自动化、shell 执行、文件写入和任意代码的爆炸半径并不相同。浏览不受信任的站点可能触发恶意下载、凭据窃取尝试或通过过于宽泛的网络访问进行横向移动。Shell 命令可能转向软件包安装、进程检查或机密发现。文件写入可能破坏工作状态或为后续阶段植入可执行内容。任意代码执行是最锋利的边缘——它将文件系统、进程和网络滥用结合在一步之中。我们的首要建议很直接：对 AI 智能体沙箱化使用分层模型，而非对所有任务采用单一隔离级别。

将隔离与工作负载匹配

基于容器的加固智能体执行沙箱适用于确定性的高吞吐量工作：HTML 解析、测试运行器、文档转换，或对可信仓库进行 lint 检查。容器速度快且运维高效，我们可以通过命名空间、cgroups、seccomp、AppArmor 或 SELinux、只读根文件系统以及 no-new-privileges 来加固它们。但它们仍然共享宿主机内核。这种共享内核边界正是核心风险所在。

临时虚拟机或 microVM——例如由 Firecracker 支持的工作节点、Kata Containers 或类似的客户机内核设计——是应对恶意浏览会话、用户提供的脚本或来源不明的代码执行的更好选择。它们启动更慢、成本更高，并增加编排开销。即便如此，它们能降低内核级逃逸从一个租户进入宿主机所带来的后果。

| 方案 | 隔离强度 | 启动/成本 | 理想用例 |
| --- | --- | --- | --- |
| 加固容器 | 中等；共享宿主机内核 | 最快、成本最低 | 可信仓库构建、解析、转换 |
| gVisor/Kata 风格容器隔离 | 中高；额外运行时边界 | 中等 | 混合信任的 shell 任务、更安全的多租户作业 |
| 临时虚拟机或 microVM | 最高；每个任务独立客户机内核 | 最慢、成本最高 | 不可信浏览、任意代码、用户脚本 |

实用选择规则

当任务有边界、可复现且易于撤销时，使用容器。当智能体可以执行任意代码、浏览未知域名或处理具有重大业务影响的机密时，使用临时虚拟机。在智能体执行沙箱中，清晰的威胁边界同样重要。

针对每个执行面的 AI 智能体沙箱：浏览器、shell、文件访问和代码执行

大多数智能体故障并非始于戏剧性的沙箱逃逸，而是始于能力蔓延。这就是为什么实用的 AI 智能体沙箱会有意收窄每个执行面，然后记录仍然发生的事情。

浏览器自动化

不要给浏览器会话共享状态。为每个任务使用浏览器配置文件隔离，禁用宿主机剪贴板访问，并将下载限制到受控目录，或在任务不需要检索时阻止下载。通过具有明确出站规则的专用出站代理路由流量。

阻止访问云元数据端点、适当情况下的 RFC1918 地址范围以及内部管理 URL。浏览智能体不应因为页面触发重定向而访问 169.254.169.254、集群控制平面或私有仪表板。这是预防，而非可观测性。

这正是隔离选择变得具体的地方。对于针对不可信站点的高风险浏览，优先使用临时虚拟机或 microVM，而不是普通容器。共享内核容器沙箱速度很快，但浏览器漏洞利用链足以证明需要更强的隔离。

Shell 命令

Shell 访问从一开始就应当是非交互式的。没有 TTY。没有 SSH。没有长生命周期会话。以结构化作业的形式执行命令，具有固定的工作目录、超时、通过 cgroups 设置的 CPU 和内存配额，以及禁用权限提升。

在任务空间已知的情况下使用命令允许列表。如果这过于僵化，则允许一小组工具集，并阻止包管理器、网络扫描器、挂载操作和用户管理命令。将工作目录限制在任务工作区内，并在可能的情况下以只读方式挂载根文件系统。

保持 shell 策略可读。隐藏在脚本中的微小例外会迅速变成安全债务。

文件访问

将文件访问范围限定在工作区，而不是整台机器。智能体应只能看到任务批准的路径，参考数据以只读方式挂载，写入操作使用每个任务的临时工作区。完成后删除该临时存储。

这听起来可能很严格，但它能防止常见故障。如果智能体编辑了错误的文件、遵循了内容中的恶意指令，或试图枚举相邻目录，这可以缩小影响范围。

代码执行

AI 代码执行沙箱需要硬性运行时限制和一次性环境。设置内存、CPU、进程数和挂钟时间限制。将语言运行时限制为已批准的解析器或镜像，并强制执行包安装策略——通常不允许在运行时安装，或仅允许从内部镜像安装。

对于较低风险的任务，使用通过 seccomp、AppArmor 或 SELinux 加固的容器，以及只读根文件系统。当影响范围较大时，将不受信任或用户提供的代码移入由 Firecracker、Kata Containers、gVisor 或临时虚拟机支持的智能体执行沙箱。

防止滥用和实现可观测性是独立的控制措施。记录命令、文件路径、网络目标、退出码和审批事件，但不要将日志误认为隔离。

安全的 AI 智能体运行时两者兼顾。

AI 智能体沙箱需要网络出口控制、文件系统隔离和硬性资源限制

审批门控有帮助，但无法限制爆炸半径。一个已批准的浏览器会话仍可能将数据发送到错误的主机，一个已批准的 shell 步骤仍可能陷入嘈杂的循环，而如果运行时暴露了过多宿主机资源，一个文件编辑智能体仍可能覆盖共享状态。每个 AI 智能体沙箱设计都需要在审批之前、期间和之后都适用的护栏。

首先采用默认拒绝的网络出口策略

从零出站访问开始，然后仅将任务所需的内容加入允许列表。在实践中，这通常意味着通过出口代理路由流量，在那里执行目标策略，并阻止沙箱本身直接访问互联网。对主机名和 IP 范围都应用策略，因为如果解析发生在其他地方，仅靠 DNS 规则很容易被绕过。

DNS 需要有自己的控制措施。强制沙箱化工作负载使用经批准的解析器，阻止原始出站 DNS，并默认拒绝访问云元数据端点和内部管理网络。这对于浏览器自动化或用户提供的代码最为重要，因为提示注入可能将无害任务转变为数据外泄。

审批工作流不能替代出口控制；它们决定一个操作是否启动，而不是一旦运行后可以将数据发送到哪里。

文件系统隔离必须平淡无奇且严格

默认使用只读根文件系统。为每个任务提供自己隔离的可写卷，用于临时输出、下载或生成的代码，然后在执行后删除它。宿主机挂载应该罕见、狭窄且明确，理想情况下是单一用途的绑定挂载，而不是对共享工作目录的广泛访问。

对于更高风险的工作负载，添加系统调用和 MAC 控制，例如 seccomp 和 AppArmor 或 SELinux，或者将任务移动到更强的隔离边界中，例如 gVisor、Kata Containers 或临时 VM。更简单的挂载布局更容易推理，也更难被误用。

硬性资源限制可阻止代价高昂的故障

为每个任务设置 CPU 配额、内存限制、PID 限制和墙钟超时。使用 cgroups 进行 CPU 和内存控制，限制进程创建以阻止 fork 炸弹，并终止超过运行时间的任务。

一个简单的故障模式是代码生成智能体编写一个递归脚本并执行它。如果没有限制，它可能耗尽内存、生成子进程并降低宿主机性能。在设计良好的沙箱中，内存限制会首先触发，PID 上限会阻止进程扇出，而墙钟超时可保证清理。

这就是 AI 智能体的基线沙箱化：不是在所有地方都实现最大隔离，而是在信任进入对话之前，每个运行时都需要的最低控制措施。

设定审批边界、保护凭据，并为沙箱逃逸尝试做好规划

安全总是最先在边缘处崩溃。如果审批策略模糊不清，或者密钥存放在智能体可以发现的位置，那么运行时加固也救不了你。在调整运行时之前先设定审批策略。如果沙箱拥有广泛的能力，一个看似无害的提示词仍然可能造成破坏性副作用。使用基于能力的审批边界，而不是基于提示词的边界。

将人类置于高风险边缘

对于会改变沙箱外部状态或触及敏感信任区域的操作，自主执行应当停止。以下操作需要审批：

• 破坏性 shell 命令，如 rm、软件包安装、进程控制或系统配置更改

• 对外部系统的写入，如 Git push、工单更新、数据库更改、对象存储上传、邮件或 webhook 调用

• 对敏感路径的读取，如 SSH 材料、.env 文件、生产配置或客户数据导出

• 针对生产数据的代码执行，即使在加固的沙箱中也是如此

• 浏览器导航到未知域名、文件下载或表单提交

审批应当绑定到能力和目标上，而不是用户的措辞。保持提示词具体明确，以便操作人员审查真实风险，而不是在模糊的警告中一路点击通过。

将密钥隔离在工作区之外

使用短期凭据、限定范围的服务账户，以及从代理或保险库进行的运行时密钥注入。不要将密钥烘焙到镜像中，也不要将其持久化到沙箱磁盘上。通过环境变量或 tmpfs 挂载传递令牌，积极轮换它们，并阻止元数据端点，使浏览器或 shell 步骤无法访问云凭据。

工作区中零持久化密钥应当是对 AI 智能体进行沙箱化的硬性要求。

假设逃逸尝试将会发生

容器速度很快，但共享内核使内核逃逸成为核心风险。通过 seccomp、AppArmor 或 SELinux、只读根文件系统、丢弃 Linux 能力以及 cgroups 来加固它们。对于不受信任的代码或高风险浏览，使用更强的隔离，如 gVisor、Kata Containers、Firecracker 或临时虚拟机。定期打补丁，并对工作负载进行隔离，使低风险的解析任务不会与高风险的浏览器会话共享主机。

生产环境中带审计日志和决策框架的 AI 智能体沙箱化

如果你无法重建智能体（Agent（智能体））做了什么，你就没有准备好上生产环境。生产就绪始于可解释性。如果你无法重建智能体做了什么，你的 AI 智能体沙箱化就没有准备好用于真实工作。

按任务身份记录审计追踪：提示或计划引用、有效能力、命令行、读取或写入的文件路径、网络目的地、审批事件、请求的密钥、退出状态，以及 CPU、内存和运行时使用情况。在策略允许的情况下保留 stdout 和 stderr。存储对敏感载荷的引用，而不是原始密钥材料，并让时间戳、任务 ID 和父子操作 ID 足够一致，以支持事件审查。结构化日志还有助于将策略失败与模型错误、操作员错误和正常任务差异区分开来。

在此基础上，按风险而不是按习惯选择隔离。使用隔离分层，而不是一刀切的控制。一个实用的标准是：

• 低风险：在加固的容器中进行内部解析或范围严格受限的转换，并启用 seccomp、AppArmor 或 SELinux、cgroups，以及只读根文件系统。

• 中风险：在更强的沙箱（如 gVisor 或 Kata Containers）中进行文件编辑、软件包安装或受限出站的 shell 步骤。

• 高风险：在临时 VM 或基于 Firecracker 的 microVM 中，对不受信任的站点进行浏览器自动化、运行用户提供的代码，或进行广泛的外部连接。

当任务获得互联网访问、处理不受信任的输入、接触凭据，或可能更改持久状态时，提升层级。如果一项工作从受信任的仓库测试转变为带网络访问的任意上传代码，请在它用艰难的方式逼你之前，先将其提升一个层级。

以清单式思维运行运行时：能力、审批、出站、存储、限制、日志，然后是例外。

常见问题

用实际术语来说，什么是 AI 智能体沙箱化？

AI 智能体沙箱化是隔离、策略执行和监控的组合，用于限制自主智能体在任务期间可以执行、访问和传输的内容。在实践中，这意味着只给智能体提供该特定工作所需的最低运行时、网络、文件系统和凭据访问权限。

AI 智能体沙箱化与普通应用安全有何不同？

普通应用安全假设软件遵循预定义流程，而 AI 智能体沙箱化假设系统可能在运行时生成新操作。这一差异很重要，因为控制模型必须约束涌现行为，而不仅仅是已知端点，要通过围绕工具、数据和外部副作用强制执行能力边界来实现。

为什么某些智能体任务应使用临时 VM 而不是容器？

当任务涉及恶意网站、不受信任的代码或敏感凭据时，临时虚拟机（Ephemeral VM）是更安全的默认选择，因为它们将工作负载隔离在客户机内核之后，而不是共享宿主机内核。这种额外的边界会增加启动成本，但它实质性地降低了容器逃逸或内核级漏洞利用的影响。

当智能体需要调用外部服务时，我该如何保护凭据？

最安全的模式是在执行前签发短期、严格限定范围的凭据，并在任务结束时自动撤销它们。凭据应通过代理或保险库（vault）传递，绝不能存储在镜像或长期存在的工作区中，并且要加以限制，使泄露的令牌无法在预期的 API 或时间窗口之外被重用。

生产环境智能体的审计日志除了基本命令历史之外还应包含哪些内容？

有用的生产日志应在关联时间线中记录智能体身份、任务目标、工具调用、有效权限、审批决策、出站目的地、文件产物、时间信息和资源消耗。这种详细程度使事后事件重建成为可能，并有助于将策略违规与正常任务执行噪声区分开来。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：DEV.to

原创地址：https://dev.to/imversion_tech/ai-agent-sandboxing-practical-guide-for-production-safety-58p8