Marico's space

最近在项目中跑了几个 AI Agent（人工智能代理），踩了几个深坑才把安全问题理清楚。这篇不废话，直接把 AI Agent 沙箱化的核心思路和生产实践讲明白。

AI Agent 沙箱化是安全自主操作的控制平面

问题出在 Agent 的执行速度比你的防护机制快的时候。浏览器自动化、Shell 命令、文件访问、代码执行，这些能力在 Agent 拿到不该碰系统的广泛权限之前都挺好用的。AI Agent 沙箱化就是让自主操作可控可用，而不是变成开放的系统访问权限。沙箱给 Agent 能触及、修改、窃取的内容划了硬边界。

实际选择很简单，哪怕实现起来不简单——用容器保证速度和吞吐，用临时虚拟机（ephemeral VM）或微虚拟机（microVM）处理不可信代码或恶意网页场景。然后在安全的 AI Agent 运行时上叠加出站流量控制、只读文件系统、资源控制组（cgroups）、系统调用过滤（seccomp）、AppArmor 或 SELinux、审批门禁和审计日志。

我们把 AI Agent 沙箱当作控制平面来设计，不只是一个包装壳。沙箱化的核心是爆炸半径。一个缺少元数据端点拦截、凭证隔离、命令和文件路径日志的快速执行沙箱仍然不安全。用户体验也很重要——审批提示和日志必须足够清晰，让人类能快速做出判断。

关键要点

• 从一开始就把 Agent 当作不可信的操作者。AI Agent 沙箱化的默认策略是最小权限，阻止元数据端点，通过代理限制出站流量，文件系统默认只读除非任务确实需要写入。
• 使用分层隔离，不是一套策略管所有场景。低风险的解析或测试跑在容器加固的沙箱里；不可信网站的浏览器自动化和任意代码跑在临时虚拟机或微虚拟机里。
• 运行时隔离还不够。审批门禁、短生命周期凭证、密钥作用域和沙箱本身同样重要。
• 记录每个操作——命令、文件路径、网络目标、审批事件和产物哈希。清晰的审计轨迹更容易维护和信任。

先做威胁建模：选容器还是临时虚拟机之前，先把 Agent 操作映射清楚

团队常犯的错误是从基础设施开始。Docker、Firecracker 或 gVisor 可能是最终选择，但不该是第一步讨论。正确的 AI Agent 沙箱来自于评估任务在 Agent 行为异常、被提示注入或接触到恶意输入时可能造成的损害。

浏览器自动化、Shell 执行、文件写入、任意代码执行的风险等级不同。在不可信网站上浏览可能触发恶意下载、凭证窃取或通过网络访问过于宽泛导致的横向移动。Shell 命令可以切换到安装包、检查进程或发现密钥。文件写入可能破坏工作状态或植入可执行内容供后续使用。任意代码执行是最锋利的边缘——它把文件系统、进程和网络滥用一步搞定。我们的第一个建议很简单：AI Agent 沙箱化要用分层模型，不是一个隔离级别应付所有任务。

隔离级别要匹配工作负载

加固的基于容器的 Agent 执行沙箱适合确定性、高吞吐的工作：HTML 解析、测试运行器、文档转换或可信仓库的代码检查。容器快速高效，我们可以用命名空间、资源控制组、系统调用过滤、AppArmor 或 SELinux、只读根文件系统和 no-new-privileges 来加固。但它们仍然共享主机内核。这个共享内核边界是核心风险所在。

临时虚拟机或微虚拟机——比如 Firecracker 后端的 Worker、Kata Containers 或类似的客户内核设计——是对抗恶意浏览会话、用户提交脚本或来源不明的代码执行时更好的选择。它们启动更慢、成本更高、编排开销更大。即便如此，它们降低了从一个租户的内核级逃逸进入主机的后果。

实用选择规则

当任务有界、可复现、易撤销时用容器。当 Agent 可能执行任意代码、浏览未知域名或处理有重大业务影响的密钥时用临时虚拟机。在 Agent 执行沙箱里，清晰的威胁边界至关重要。

每个执行面的 AI Agent 沙箱化：浏览器、Shell、文件访问、代码执行

大多数 Agent 失败不是从戏剧性的沙箱逃逸开始，而是从能力蔓延开始。所以实用的 AI Agent 沙箱要主动收窄每个攻击面，然后记录仍然发生的事情。

浏览器自动化

不要让浏览器会话共享状态。每个任务用独立的浏览器配置文件，禁用主机剪贴板访问，限制下载到受控目录或除非任务需要检索否则直接阻止。把流量路由到专用的出站代理并配置明确的出口规则。

阻止访问云元数据端点、RFC1918 私有地址段（适当场景）和内部管理 URL。浏览 Agent 不应该因为某个页面触发重定向就触及 169.254.169.254、集群控制平面或私有仪表盘。这是预防，不是观测。

隔离选择在这里变得具体。对于高风险浏览不可信网站，优先选临时虚拟机或微虚拟机，而不是普通容器。共享内核的容器沙箱虽然快，但浏览器漏洞利用链值得更强的隔离。

Shell 命令

Shell 访问从一开始就该是非交互式的。不要 TTY、不要 SSH、不要长生命周期会话。把命令作为结构化作业执行，固定工作目录、超时、CPU 和内存配额通过 cgroups 实现、禁用权限提升。

在任务范围已知时使用命令白名单。如果太严格，就允许一个小工具集然后阻止包管理器、网络扫描器、挂载操作和用户管理命令。把工作目录限制在任务工作空间，可能的话把根文件系统挂载为只读。

保持 Shell 策略可读。埋在脚本里的小例外很快变成安全债务。

文件访问

把文件访问限定在工作空间，不是整台机器。Agent 只应该看到任务批准过的路径，参考数据用只读挂载，写操作在每个任务独立的临时工作空间。执行完成后删除临时存储。

这听起来严格，但能防止常见失败。如果 Agent 编辑了错误文件、在内容中遵循了恶意指令、或试图枚举相邻目录，这能减少爆炸半径。

代码执行

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

低风险任务用 seccomp、AppArmor 或 SELinux 加固的容器加只读根文件系统。不可信或用户提交的代码在爆炸半径更大时移到 Firecracker、Kata Containers、gVisor 或临时虚拟机支撑的 Agent 执行沙箱里。

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

安全的 AI Agent 运行时两者都要做。

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

审批门禁有帮助，但不包含爆炸半径。审批通过的浏览器会话仍然可能向错误的主机发送数据，审批通过的 Shell 步骤仍然可能陷入大量循环，文件编辑 Agent 如果运行时暴露了太多主机内容仍然可能覆盖共享状态。每个 AI Agent 沙箱化设计都需要在审批前、审批中、审批后都起作用的防护栏。

先做默认拒绝的出站网络控制

从零出站访问开始，然后只放行任务需要的部分。实践中通常意味着把流量路由到出站代理，在代理层强制目标策略，阻止沙箱直接访问互联网。对主机名和 IP 段都应用策略，因为单靠 DNS 规则容易被绕过——如果解析在别处发生的话。

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

审批流程不能替代出口控制；它们决定动作是否开始，不决定运行时数据可以发到哪里。

文件系统隔离必须无聊但严格

默认使用只读根文件系统。每个任务给独立的隔离可写卷用于临时输出、下载或生成的代码，执行后删除。主机挂载应该少见、狭窄、明确，最好是单一用途的绑定挂载而不是宽泛访问共享工作目录。

对于更高风险的工作负载，添加系统调用和 MAC（强制访问控制）比如 seccomp、AppArmor 或 SELinux，或者把任务移到更强的隔离边界如 gVisor、Kata Containers 或临时虚拟机。更简单的挂载布局更容易推理，也更难被滥用。

硬性资源限制阻止昂贵的失败

给每个任务设置 CPU 配额、内存限制、进程数限制和壁钟超时。用 cgroups 控制 CPU 和内存，限制进程创建以阻止 fork 炸弹，超时的任务直接杀掉。

一个简单的失败模式：代码生成 Agent 写了个递归脚本然后执行。没有限制的话它会耗尽内存、派生子进程、拖垮主机。在设计良好的沙箱里，内存限制先触发，进程数上限阻止进程扩散，壁钟超时保证清理。

这是 AI Agent 基线沙箱化：不是到处用最高隔离，而是信任进入对话前每个运行时都需要的最少控制。

设置审批边界、保护凭证、计划沙箱逃逸应对

安全在边缘最先崩溃。如果审批策略模糊，或者密钥放在 Agent 能发现的地方，运行时加固也救不了你。先定审批策略再调运行时。如果沙箱有广泛能力，看似无害的提示仍然可能造成破坏性副作用。用基于能力的审批边界，不是基于提示词。

让人站在风险边缘

自主执行应该在改变沙箱外状态或触及敏感信任区域的行动前停下。需要审批的操作包括：

• 破坏性 Shell 命令如 rm、包安装、进程控制或系统配置变更
• 写入外部系统如 Git 推送、工单更新、数据库变更、对象存储上传、邮件或 webhook 调用
• 读取敏感路径、SSH 材料、.env 文件、生产配置或客户数据导出
• 针对生产数据的代码执行，即使在加固的沙箱里
• 浏览器导航到未知域名、文件下载或表单提交

审批应该附加在能力和目标上，不是用户措辞上。保持提示具体让操作员审查真实风险，而不是点过模糊警告。

让密钥远离工作空间

使用短生命周期凭证、限定作用域的服务账号和从代理或密钥库运行时注入的密钥。不要把密钥烘焙到镜像里或持久化到沙箱的磁盘上。通过环境变量或 tmpfs 挂载传递令牌，积极轮换，阻止元数据端点让浏览器或 Shell 步骤无法触及云凭证。

工作空间零持久化密钥应该是 AI Agent 沙箱化的硬性要求。

假设逃逸尝试会发生

容器很快，但共享内核让内核逃逸成为核心风险。用 seccomp、AppArmor 或 SELinux、只读根、丢弃 Linux capabilities 和 cgroups 加固。对于不可信代码或高风险浏览，用更强的隔离如 gVisor、Kata Containers、Firecracker 或临时虚拟机。定期打补丁，工作负载隔离让低风险解析任务和高风险浏览器会话不共享主机。

生产环境中的 AI Agent 沙箱化：审计日志和决策框架

如果你无法重建 Agent 做了什么，你还没准备好上生产。生产就绪从可解释性开始。如果你无法重建 Agent 做了什么，你的 AI Agent 沙箱化还没准备好干正事。

按任务身份记录审计轨迹：提示或计划引用、有效能力、命令行、读写文件路径、网络目标、审批事件、密钥请求、退出状态和 CPU、内存、运行时用量。策略允许的地方保留标准输出和标准错误。存储敏感载荷的引用而不是原始密钥材料，时间戳、任务 ID 和父子操作 ID 足够一致以支持事件审查。结构化日志也有助于区分策略失败、模型错误、操作员错误和正常任务波动。

然后按风险选隔离，不要按习惯。用隔离分层，不是一刀切控制。实用规则是：

• 低风险：内部解析或严格限定的转换，跑在加了 seccomp、AppArmor 或 SELinux、cgroups 和只读根文件系统的加固容器里。
• 中风险：文件编辑、包安装或有有限出口的 Shell 步骤，跑在 gVisor 或 Kata Containers 等更强沙箱里。
• 高风险：针对不可信网站的浏览器自动化、用户提交的代码或广泛的外部连接，跑在临时虚拟机或 Firecracker 微虚拟机里。

当任务获得互联网访问、处理不可信输入、触及凭证或能改变持久状态时升级层级。如果一个任务从可信仓库测试变成有网络访问的任意上传代码，在生产环境以艰难方式替你升级之前先升一级。

用检查清单心态跑运行时：能力、审批、出口、存储、限制、日志，然后才是例外。

常见问题

AI Agent 沙箱化实际是什么？

AI Agent 沙箱化是隔离、策略执行和监控的组合，限制自主 Agent 在任务期间能执行、访问和传输的内容。实际上意味着只给 Agent 提供该特定作业所需的最小运行时、网络、文件系统和凭证访问。

AI Agent 沙箱化和普通应用安全有什么区别？

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

为什么某些 Agent 任务应该用临时虚拟机而不是容器？

当任务涉及恶意网站、不可信代码或敏感凭证时，临时虚拟机是更安全的默认选择，因为它们用客户内核隔离工作负载而不是共享主机内核。这个额外边界增加了启动成本，但显著降低了容器突破或内核级漏洞利用的影响。

Agent 需要调用外部服务时如何保护凭证？

最安全的模式是在执行前即时发放严格限定作用域的短生命周期凭证，任务结束时自动撤销。凭证通过代理或密钥库传递，绝不存储在镜像或长期工作空间里，并且限制作用域让泄露的令牌无法在预期 API 或时间窗口外被复用。

生产 Agent 审计日志除了基本命令历史还应记录什么？

有用的生产日志应该记录 Agent 身份、任务目标、工具调用、有效权限、审批决策、出站目标、文件产物、时间和资源消耗，组成关联时间线。这个详细程度让事后重建成为可能，也有助于区分策略违规和正常任务执行的噪声。