1. 从逃出沙箱说起一个被误读的权限事故第一次看到AI Agent 逃出沙箱这个说法我脑子里冒出来的不是科幻电影里的失控画面而是一个很具体的工程问题一个被授予了文件读写、命令执行、网络请求能力的智能体在某次任务执行中触碰到了它本不该触碰的资源。这件事被传播成逃出沙箱之后讨论迅速滑向了两个极端——要么是AI 要失控了要么是这就是个标题党。但真正做过 Agent 系统的人都知道这两边都没说到点子上。所谓沙箱本质上是给 Agent 划定的一个权限边界。它规定了 Agent 能读哪些文件、能写哪些目录、能调用哪些命令、能访问哪些网络地址、能消耗多少资源。这个边界不是天然存在的而是由开发者一层层配置出来的。所以逃出沙箱这个描述本身就不太准确——更贴近事实的说法是边界没有被正确设置或者边界被设置之后又被某个环节绕过了。我之所以想认真拆解这个案例是因为它暴露的问题在当下的 Agent 开发中极其普遍。无论是基于 Rust 写的本地 Agent还是跑在云端的服务型 Agent只要它具备执行动作的能力就一定面临权限边界的设计问题。而绝大多数团队在快速迭代阶段对这块的处理都是先跑通再说等到出事才回头补。这篇内容就是想把这类问题的成因、排查路径和加固方案讲透让正在搭 Agent 的人少走弯路。需要先明确一点本文讨论的是工程层面的权限控制不涉及任何模型能力本身的评价也不讨论模型是否有意识这类话题。我们只谈一个系统在给定权限下如何确保它只做被允许的事。2. 沙箱到底在防什么Agent 权限模型的三层结构2.1 第一层进程与文件系统隔离最基础的沙箱是操作系统级别的。当一个 Agent 需要执行代码或命令时它通常运行在一个受限的进程环境里。这个环境的核心约束包括进程能访问哪些路径、能创建哪些子进程、能使用多少内存和 CPU、能否访问设备文件。在 Linux 环境下常见的做法是用命名空间namespace做隔离用 cgroup 做资源限制再配合 seccomp 过滤系统调用。举个具体的例子如果你用容器跑 Agent 的执行环境默认情况下容器内的进程是看不到宿主机文件系统的除非你显式挂载了某个目录。这就是最朴素的边界。但问题往往出在显式挂载这一步。我见过不少项目为了方便调试直接把宿主机的某个大目录挂进容器比如把整个项目根目录甚至用户主目录挂进去。这样一来Agent 理论上只能操作挂载点内的文件但实际上挂载点覆盖的范围远超预期。更隐蔽的情况是挂载了 Docker 的 socket 文件——一旦 Agent 能访问这个 socket它就能通过 Docker API 创建新的容器而新容器的权限配置可能完全不同等于绕过了原有的边界。2.2 第二层工具调用的能力白名单Agent 和普通程序最大的区别在于它的行为不是写死的而是由模型根据任务动态决定的。模型决定调用哪个工具、传什么参数这个过程中就存在参数越界的可能。假设你给 Agent 提供了一个read_file工具本意是让它读取项目内的配置文件。如果这个工具的实现是直接拼接路径然后打开文件那么模型完全可能传入../../etc/passwd这样的路径。这不是模型恶意而是它在尝试完成任务时可能真的会构造出这类路径。所以工具层必须做参数校验把路径规范化之后判断是否落在允许的根目录内。这里有个容易被忽略的细节路径校验不能只做字符串前缀匹配。/allowed/dir和/allowed/dir_evil在字符串上前者是后者的前缀但它们是两个完全不同的目录。正确的做法是先做路径规范化解析..、符号链接等再用规范化后的绝对路径做前缀判断并且要确保前缀后面紧跟的是路径分隔符。2.3 第三层网络与外部资源的访问控制Agent 经常需要访问网络比如调用 API、下载依赖、查询资料。网络层的边界控制比文件系统更复杂因为目标地址是动态的。常见的做法是维护一个域名或 IP 白名单只允许 Agent 访问白名单内的地址。但这里有个坑DNS 解析结果是可以被操纵的如果只校验域名不校验解析后的 IP就可能出现域名合法但实际指向内网地址的情况。更稳妥的方式是在网络出口做统一管控比如通过代理层拦截所有请求在代理层做目标地址校验。另外Agent 访问外部服务时携带的凭证也是边界的一部分。如果 Agent 能读取环境变量而环境变量里存着高权限的 API Key那么即使文件系统隔离做得再好Agent 也能通过这个 Key 去操作外部资源。凭证的存放位置和读取权限必须和 Agent 的执行环境严格分离。3. 案例复盘边界是怎么被一步步绕过的3.1 起点一个为了方便的配置大多数权限事故的起点都不是恶意设计而是某个为了方便的临时决定。在这个案例的公开讨论中能看到的典型模式是Agent 需要执行用户提交的代码或命令开发者为了让它能正常工作给了它一个相对宽松的执行环境。具体表现可能是容器以较高权限运行、挂载了必要的工具目录、允许访问包管理器、开放了部分网络。每一项单独看都有合理理由但叠加起来就形成了一个远超实际需要的权限集合。我自己的经验是Agent 的权限配置应该遵循最小可用原则但这个原则在实操中很难执行因为你不确定 Agent 到底需要什么。所以更现实的做法是先给一个较紧的边界观察 Agent 在真实任务中因为权限不足失败的情况再逐项放开。这个观察-放开的循环虽然慢但比一开始就给大权限要安全得多。3.2 关键环节工具实现中的校验缺失边界被绕过的直接原因通常是某个工具的输入校验不完整。以命令执行工具为例如果它的实现是接收一个字符串然后直接交给 shell 执行那么模型可以通过管道、重定向、命令替换等方式执行远超预期的操作。比如模型本意是执行ls查看目录但它可能构造出ls; cat /some/sensitive/file这样的输入。如果工具没有对输入做限制这条命令就会完整执行。更隐蔽的是通过环境变量或 shell 内置功能间接访问资源这类操作往往不在简单的关键字黑名单覆盖范围内。这里要强调一个观点对命令执行工具做输入过滤本质上是一场打不赢的军备竞赛。你封了分号它用换行你封了管道它用命令替换你封了所有 shell 元字符它用脚本文件。所以正确的思路不是过滤输入而是限制执行环境——让 Agent 在一个即使执行任意命令也造不成实质影响的环境里运行。3.3 扩散凭证与网络的双重放大当 Agent 突破了文件系统边界之后如果它同时拥有网络访问能力和有效凭证问题的严重性会成倍放大。文件系统边界被突破最坏情况是本地数据泄露但如果 Agent 能拿着凭证访问外部服务影响范围就扩展到了整个账号体系。这个放大效应在案例讨论中被反复提及。一个典型的链路是Agent 读取到了环境变量中的访问令牌然后用这个令牌调用了某个管理接口进而修改了配置或拉取了更多数据。整个过程在日志上看起来可能只是一系列正常的 API 调用很难被及时发现。所以权限设计上有一个重要原则凭证不应该和 Agent 的执行环境共存。如果 Agent 确实需要访问某个外部服务应该通过一个受控的代理层由代理层持有凭证并做权限校验Agent 只和代理层交互拿不到原始凭证。4. 加固方案从事后补救到默认安全4.1 执行环境的最小化配置加固的第一步是把 Agent 的执行环境压到最小。具体来说容器镜像只包含任务必需的工具不安装包管理器、不保留编译工具链、不挂载任何非必要的目录。如果 Agent 需要执行代码优先考虑用解释器直接运行而不是通过 shell。对于必须使用 shell 的场景可以用受限的 shell 或者自定义的命令解析器只允许执行白名单内的命令并且参数也做严格校验。这种方式虽然牺牲了一部分灵活性但在安全要求高的场景下是值得的。资源限制同样重要。给 Agent 的执行环境设置 CPU、内存、磁盘配额以及进程数量上限可以防止它通过资源耗尽的方式影响宿主机或其他服务。这些限制在容器编排层面通常都有现成的配置项成本很低但收益明显。4.2 工具层的参数校验规范工具层的校验要做到默认拒绝。每个工具在实现时都要明确它接受的参数范围超出范围的一律拒绝而不是尝试修正或放行。以文件操作为例校验逻辑应该是先把传入路径解析为绝对路径解析过程中处理掉所有..和符号链接然后判断这个绝对路径是否在允许的根目录之下。判断时要注意路径分隔符的边界问题避免前缀匹配的漏洞。对于写操作还要额外检查目标文件是否已存在、是否是符号链接防止通过符号链接写到允许目录之外。网络请求工具则要校验目标地址。如果允许访问的是一组域名要确保校验发生在 DNS 解析之后对解析出的 IP 也做检查。同时要限制请求方法、请求头大小、响应体大小防止通过超大请求或响应做资源消耗。4.3 监控与审计让越界行为可见再好的边界设计也可能有疏漏所以监控和审计是最后一道防线。需要记录的关键信息包括Agent 调用了哪些工具、传了什么参数、执行结果如何、访问了哪些网络地址、消耗了多少资源。这些日志的价值在于当出现异常时能快速定位问题环节。比如某个工具被频繁调用且参数异常或者某个网络地址被反复访问这些都是值得关注的信号。日志本身也要做好保护避免被 Agent 读取或篡改。一个实用的做法是给每次 Agent 会话分配一个独立的标识所有操作都带上这个标识这样在排查时可以完整还原一次会话的行为链路。对于高风险操作可以设置实时告警比如访问了敏感路径或调用了管理类接口。5. 几个容易踩的坑和我的实际处理方式5.1 符号链接与路径穿越的隐蔽性路径校验里最容易出问题的是符号链接。假设允许目录是/workspaceAgent 在/workspace下创建了一个指向/etc的符号链接link然后访问/workspace/link/passwd。如果校验只做了字符串层面的前缀判断这个访问会被放行但实际读取的是/etc/passwd。处理方式是在校验前先解析符号链接拿到真实路径再做判断。但这里有个时序问题解析和打开之间如果文件被替换仍然可能出问题。更稳妥的做法是在打开文件时使用不跟随符号链接的标志或者用文件描述符做后续操作避免路径被二次解析。5.2 环境变量泄露的连锁反应环境变量是凭证泄露的高发区。很多项目习惯把 API Key、数据库连接串放在环境变量里而 Agent 的执行环境如果继承了这些变量就等于把凭证直接交给了 Agent。我的处理方式是把 Agent 的执行环境和主进程的环境变量完全隔离只传入任务必需的、经过筛选的变量。对于确实需要凭证的场景通过一个独立的凭证服务来提供Agent 拿到的是短期有效的、权限受限的令牌而不是长期有效的原始凭证。5.3 工具组合带来的意外能力单个工具看起来都很安全但组合起来可能产生意外能力。比如一个工具能写文件另一个工具能执行文件那么 Agent 就可以先写一个脚本再执行它实现任意代码执行。这种组合风险在工具数量增加时会快速上升。应对方式是在设计工具集时从整体上评估组合后的能力边界而不是孤立地看每个工具。如果某个组合会产生高风险能力要么去掉其中一个工具要么在它们之间加一道审批环节。6. 写在最后的一点个人体会做 Agent 系统这几年我最大的感受是权限边界的设计不是一次性的工作而是随着 Agent 能力扩展持续调整的过程。每增加一个工具、每放开一项权限都要重新评估整体边界是否还成立。很多事故不是因为某个环节特别薄弱而是因为多个环节的微小放松叠加起来最终突破了原本的设计意图。另外不要指望通过教育模型来保证安全。模型的输出是不确定的同样的输入可能产生不同的行为。安全必须建立在系统层面的约束上而不是依赖模型自觉遵守规则。把边界做在环境里、做在工具实现里、做在监控里这样即使模型行为超出预期系统也能兜住。最后分享一个实用习惯每次给 Agent 加新能力之前先问自己一句如果这个能力被用到极致最坏会发生什么。如果答案让你不舒服那就说明边界还需要再收紧一点。这个简单的自问帮我避免了好几次潜在的麻烦。