一、开篇AI Agent 越能干越需要一堵真正的墙过去很多人谈 AI 编码工具最关心的是模型聪不聪明、能不能读懂项目、能不能自动改文件、能不能跑命令。但当一个 Agent 真正拥有终端执行能力之后问题就变了它不只是一个“会聊天的助手”而是一个可以启动脚本、调用工具、访问网络、读取文件、写入配置的自动化执行体。这时安全边界就不能只停留在“提示词写得更谨慎”“权限弹窗多问几次”“分类器判断一下风险”这些层面。因为这些手段都属于应用层软边界一旦恶意命令进入操作系统子进程、脚本、构建工具、包管理器都可能继续放大风险。沙箱系统的价值就是把“能不能访问某个文件、能不能连某个域名、能不能写某个目录”交给操作系统级机制裁决。模型再聪明也不能越过内核边界提示注入再隐蔽也不能凭一段文字偷走 SSH 密钥。二、为什么权限弹窗还不够真正的风险来自“命令已经跑起来之后”很多人以为只要每次执行命令前都让用户点一下确认就足够安全。这个想法在早期还能成立因为 Agent 能做的事情有限。但当 Agent 开始自动修复测试、自动安装依赖、自动搜索文件、自动运行脚本后用户面对的是大量重复审批。审批越多注意力越容易下降最后就会变成“反正都点允许”。权限弹窗的问题不是它完全没用而是它无法覆盖命令运行后的复杂行为。一个看起来普通的构建命令可能会触发包管理器下载依赖一个普通的测试命令可能会执行项目脚本一个普通的 Git 操作可能会触发 hooks 或辅助进程。真正的风险往往藏在“主命令之后的子行为”里。因此安全体系需要分层模型侧判断意图权限系统判断请求分类器判断风险而沙箱负责兜底。前几层可以犯错但最后一层不能轻易被绕过。安全手段作用位置优势短板提示词约束模型生成前成本低能指导模型行为无法强制约束系统调用权限弹窗命令执行前用户可感知可人工确认频繁弹窗会导致审批疲劳风险分类器执行前判断可自动放行低风险操作误判时仍可能漏放危险动作操作系统沙箱进程运行时强制限制文件与网络访问需要配置白名单和平台适配三、沙箱到底是什么不是虚拟机而是一圈进程级护栏沙箱并不等于重新开一台虚拟机也不一定需要完整容器。这里的关键思想是让命令在一个受限制的进程环境里运行。它仍然可以执行开发任务但只能在允许范围内读写文件、访问网络和使用本地资源。对 AI Agent 来说沙箱至少要解决两个核心问题第一不能让被诱导的命令随意读取主机敏感文件第二不能让命令随意向外部服务器发送数据。文件系统隔离解决“偷文件”网络隔离解决“传出去”。两者缺一不可。Anthropic 公开介绍过这套思路Claude Code 的沙箱基于操作系统原语把 Bash 工具运行在限定边界内文件系统隔离默认只允许当前工作目录的读写边界网络隔离通过代理控制出站域名并在越界时通知用户确认。开源的 sandbox-runtime 也说明了它基于 macOS sandbox-exec、Linux Bubblewrap 和代理式网络过滤实现轻量级隔离。四、双平台隔离架构macOS 靠 SeatbeltLinux 靠 Bubblewrap跨平台是这套系统最难的地方之一。macOS 和 Linux 提供的隔离能力并不一样不能简单写一套规则到处运行。macOS 更像是通过 Seatbelt Profile 声明哪些路径可以访问、哪些路径不能访问Linux 则更像是借助 Bubblewrap 组合命名空间、只读挂载、可写 bind-mount再配合 seccomp 过滤系统调用。这种差异会直接影响产品设计。比如 macOS 的规则可以更自然地描述某些路径匹配而 Linux 的 bind-mount 更偏向精确路径macOS 对 Unix Socket 的路径级控制更友好而 Linux 的 seccomp 很难知道某个 Socket 具体对应哪个路径只能做更粗粒度的取舍。WSL2 可以复用 Linux 的隔离能力因为它有完整的 Linux 内核能力WSL1 则不适合因为缺少这类命名空间支持。这也是为什么一个成熟的 Agent 安全系统必须首先识别平台再选择合适的底层实现而不是假设所有系统都一样。平台底层机制文件系统隔离方式网络隔离方式关键注意点macOSSeatbelt Profile / sandbox-exec通过规则描述路径访问代理 部分 Socket 路径控制开箱可用能力更强LinuxBubblewrap seccomp只读根挂载 可写 bind-mount代理 系统调用限制更依赖依赖安装与精确路径WSL2同 Linux同 Linux同 Linux需要完整内核能力WSL1不适合能力不足能力不足无法提供可靠隔离五、适配器模式把复杂平台差异收进统一入口如果上层业务直接感知 Seatbelt、Bubblewrap、seccomp、代理、路径规则、平台差异系统会很快变得难以维护。所以这套设计引入了一个适配器层上层只面对统一的 SandboxManager底层由 sandbox-runtime 处理不同操作系统的实际隔离方式。这种结构很像电源适配器。应用层只需要知道“我要初始化沙箱”“我要判断是否可用”“我要包装一条命令”“我要清理命令执行后的现场”至于 macOS 还是 Linux、使用什么参数、路径怎么挂载、网络怎么代理都交给底层实现。更关键的是适配器层并不只是简单转发。它还负责把应用内概念翻译成底层配置五层设置系统、权限规则、额外目录、Worktree 主仓库路径、企业策略锁定、命令排除列表等都会在这里被合并、解析、转换。六、初始化生命周期不是打开开关而是建立一条持续更新的安全链路沙箱初始化不是“开关打开就完事”。它需要先判断功能是否启用再检测当前平台是否支持还要识别 Git Worktree 主仓库路径把多个配置源合并成运行时配置然后初始化底层隔离能力。更细的地方在于初始化过程还要避免重复初始化带来的竞态问题。为什么要检测 Worktree因为 Worktree 的 .git 通常不是一个目录而是一个指向主仓库内部路径的文件。很多 Git 操作会写入主仓库的 index.lock 等文件。如果沙箱只允许当前目录写入Git 可能无法正常工作。所以系统需要提前识别主仓库路径并把必要路径加入可写白名单。初始化完成后还不能假设配置永远不变。用户可能通过命令添加目录企业策略可能下发新配置项目设置可能调整网络域名。因此系统还要订阅设置变化把新配置同步给底层沙箱。真正成熟的安全系统必须是动态可更新的。七、五层配置优先级既要给用户自由也要给企业强控制AI Agent 安全配置最难平衡的是两件事个人开发者需要灵活企业管理员需要强制。个人可能希望为某个项目临时开放 npm、cargo、pip 等常用域名企业则可能要求所有人必须开启沙箱、必须禁止绕过、必须只允许访问内部代理。因此这套配置体系采用了多层优先级。低优先级配置提供默认值高优先级配置负责覆盖或锁定。用户设置适合个人偏好项目设置适合团队共享本地设置适合当前机器临时调整命令行标志适合启动时覆盖企业托管策略则拥有最高控制权。最高优先级的企业策略不是简单“覆盖一个字段”而是能够改变合并语义。比如当企业开启只允许托管域名时用户层和项目层的网络白名单会被忽略只保留企业策略中的域名。这就把“建议遵守”变成了“不能绕过”。配置层级适合放什么安全意义用户设置个人常用偏好和默认行为方便个人长期使用项目共享设置团队认可的目录和域名让项目成员行为一致本地设置当前机器特殊路径避免污染团队配置命令行标志一次性启动控制用于调试和临时切换企业托管策略强制开启、禁止绕过、网络收口组织级合规硬门控八、文件系统隔离只读根目录 可写白名单 高危拒绝路径文件系统隔离的核心思想非常朴素默认不要给写权限只给必要位置写权限。当前项目目录通常需要写因为 Agent 要改代码临时目录需要写因为命令运行中会产生临时文件额外目录需要用户明确加入Git Worktree 的主仓库路径在特定场景下需要兼容。真正体现安全工程水平的是“拒绝写入”的硬编码路径。设置文件不能让模型改企业托管策略目录不能让模型改技能目录也不能随便改。因为这些文件一旦被篡改就可能反过来改变 Agent 的权限、行为和能力相当于让攻击者改了控制面。这就像一栋楼的门禁系统住户房间可以进公共走廊可以走但门禁机房、电梯控制室、消防控制室不能随便进。Agent 可以写项目代码但不能修改控制自己权限的配置。路径类型默认策略原因当前工作目录通常允许读写Agent 需要完成开发任务临时目录允许写入命令运行需要缓存和临时文件额外加入目录按用户或项目配置允许支持多目录项目与工具链设置文件拒绝写入防止模型绕过权限或关闭沙箱技能目录拒绝写入技能与命令/Agent 具有高权限影响Git 敏感文件存在则只读不存在则执行后清理防止裸仓库攻击链路九、网络隔离不是禁止联网而是让联网走白名单和代理完全禁止网络当然安全但开发任务往往离不开网络安装依赖、访问包仓库、拉取文档、调用内部服务都需要联网。因此更现实的方案不是“一刀切断”而是“只允许去被认可的地方”。网络隔离采用域名白名单和代理通道。沙箱内的进程不能自由直连外部世界而是通过受控代理访问网络。代理负责检查目标域名是否允许如果是已授权域名就放行如果是未知域名就阻断或进入确认流程。企业场景里这一层尤其重要。管理员可以让所有网络访问都经过代理从而具备审计能力也可以启用只允许托管域名策略让个人和项目层的域名配置失效。这样就能防止被提示注入诱导后把敏感信息发往攻击者服务器。这里还有一个很细的工程权衡为了让部分 Go 工具在代理和自定义证书环境下正常验证 TLS系统可能提供较弱网络隔离选项。但这个选项会降低安全性因为某些系统服务可能成为数据外泄通道。所以它必须被明确标注为风险开关而不是普通兼容选项。十、Bash 工具集成每条命令都要先过一条决策链沙箱最终要落到 Bash 工具上。因为 AI Agent 的很多能力都来自命令执行查文件、跑测试、装依赖、调构建、做 Git 操作。只要 Bash 能力不受控其他安全设计就很难闭环。命令进入执行器之前系统会先判断沙箱是否启用如果没启用就走普通执行如果启用了再判断是否请求绕过沙箱如果企业策略不允许绕过绕过请求会被忽略随后再判断命令是否命中排除列表最后才决定是否进入沙箱包装。排除列表的存在是为了兼容那些很难在沙箱里正常工作的命令比如需要直接访问 Docker、systemctl 或某些系统服务的命令。但排除列表不是安全边界只是工程兼容开关。被排除的命令本质上就是回到了更弱的保护状态。Bash 命令进入沙箱前的决策链决策点可能结果安全含义沙箱未启用直接执行没有 OS 级隔离请求绕过且策略允许直接执行用于兼容但风险最高请求绕过但策略禁止仍然进入沙箱企业硬约束生效命中排除命令直接执行只适合可信场景默认路径包装进沙箱执行推荐路径十一、Bare Git Repo 攻击防御最值得学习的安全细节整个沙箱设计里最精彩的案例是对 Bare Git Repo 攻击链路的防御。这个问题的本质是攻击者可以诱导 Agent 在目录中种下一些 Git 特征文件让后续非沙箱 Git 操作把当前目录误判为裸仓库再通过 Git 配置触发外部脚本执行。这类风险非常隐蔽因为攻击不一定发生在当前命令里。恶意文件可以先被“种下”等后续某个正常 Git 操作触发时再执行。也就是说安全系统不能只盯着当前命令是否危险还要处理命令留下来的危险残留物。防御思路分两条线对于已经存在的 Git 敏感文件加入拒绝写入或只读保护对于原本不存在、可能被攻击者新建的可疑文件在沙箱命令结束后统一清理。这样既避免破坏正常 Git 行为又能切断攻击者植入触发器的路径。这个细节说明了一个安全工程原则真正的防御不是“把所有东西都锁死”而是在不破坏正常开发体验的前提下精确识别攻击链路中的关键节点然后把它拆掉。十二、企业策略从个人可选到组织强制个人使用 AI 编码工具时沙箱可以是一个增强安全的选项但在企业里它更像是一项基础治理能力。企业关心的不只是单个开发者是否方便而是敏感凭证、内部代码、生产环境配置、客户数据和审计要求是否可控。因此企业需要几个关键能力第一强制启用沙箱第二当沙箱不可用时直接失败而不是悄悄降级第三禁止模型通过危险参数绕过沙箱第四网络只允许访问企业批准的域名第五策略由托管设置下发用户本地不能覆盖。这就是从“工具配置”升级到“治理平面”。只要企业能控制最高优先级配置就可以把安全要求固化为默认行为而不是依赖每个开发者自觉配置。企业级沙箱治理路径企业能力建议策略目的强制启用沙箱开关由托管策略控制避免个人关闭失败即停止不可用时直接退出避免无保护降级禁止绕过不允许非沙箱命令自动执行防止模型突破边界域名收口只允许托管白名单防止数据外泄平台灰度先在成熟平台启用再扩展降低上线风险十三、削弱隔离选项每一个便利开关背后都有代价为了兼容复杂开发环境沙箱系统通常会提供一些弱化选项比如允许嵌套沙箱、允许较弱网络隔离、允许绕过沙箱、允许某些命令排除在沙箱之外。这些选项不是不能用而是必须清楚它们的代价。很多安全事故并不是因为系统没有安全能力而是因为为了方便把安全能力一点点关掉了。一个排除命令、一个绕过参数、一个弱化网络隔离开关单独看都像是小妥协叠加起来就可能让沙箱变成摆设。选项带来的便利潜在代价允许绕过沙箱命令失败时更容易继续执行可能完全脱离沙箱保护排除命令兼容 Docker、系统服务等特殊工具被排除命令不再受隔离保护较弱网络隔离让部分 CLI 在代理环境下正常验证证书可能打开额外外泄通道嵌套沙箱弱化兼容容器内再运行隔离工具隔离深度下降用户自定义白名单提升开发效率白名单过宽会削弱保护效果十四、普通开发者怎么落地从最小安全闭环开始如果是个人开发者不需要一上来就搭建复杂的企业策略。最实用的方式是先在日常项目中启用沙箱观察哪些命令会失败逐步补齐必要的文件路径和网络域名白名单。先启用沙箱让大部分 Bash 命令默认在隔离环境里运行。先只开放当前项目目录和必要临时目录不要一开始就开放整个用户目录。把包管理器常用域名加入白名单例如 npm、PyPI、Cargo 等实际需要的源。遇到沙箱违规时先判断是否应该加白名单而不是马上绕过沙箱。对 Docker、系统服务等特殊命令单独处理不要把排除列表写得过宽。定期检查设置文件和技能目录避免把控制面暴露给自动化命令。如果是团队可以把常用规则沉淀到项目共享配置里让每个成员少走重复配置的路。如果是企业则要用托管策略强制关键开关尤其是强制启用、禁止绕过、失败即停止、域名白名单收口。十五、从技术到认知AI Agent 安全的核心不是“不让它做事”很多人对安全的误解是越安全越不能自动化。实际上沙箱的目标恰恰相反。它不是为了让 Agent 少做事而是为了让 Agent 在安全范围内放心多做事。没有沙箱时每个命令都要人工紧盯因为一旦错了可能读走密钥、误改配置、外连泄露。有了沙箱低风险操作可以更自动越界操作被系统拦住用户只需要关注真正需要决策的部分。这才是安全与效率的平衡。未来的 AI 编码工具竞争力不只是谁的模型更强也是谁的执行环境更可信。模型负责能力上限沙箱负责安全下限。只有上限和下限同时建设起来Agent 才能从“演示很炫”走向“生产可用”。十六、总结真正可靠的 Agent需要一套操作系统级安全控制平面Claude Code 沙箱系统最值得学习的地方在于它不是单点功能而是一套完整控制平面平台适配负责跨系统运行配置优先级负责治理文件隔离负责保护本地资产网络隔离负责防外泄Bash 决策链负责执行前判断执行后清理负责切断残留攻击链企业策略负责把安全要求固化下来。把这套思路抽象出来可以得到一个非常清晰的结论AI Agent 越自主越需要硬边界越能执行真实命令越不能只靠提示词越要进入企业生产环境越必须具备配置锁定、审计、白名单和失败保护。一句话总结让模型自由发挥之前先给它建一圈不会被提示注入轻易推倒的墙。图12AI Agent 沙箱安全体系收束图参考资料https://pan.baidu.com/s/1Fm6rZSZkY3q2NcrmTfTMeQ?pwd6fkr