一、开篇：AI Agent 越能干，越需要一堵真正的墙
过去很多人谈 AI 编码工具，最关心的是模型聪不聪明、能不能读懂项目、能不能自动改文件、能不能跑命令。但当一个 Agent 真正拥有终端执行能力之后，问题就变了：它不只是一个"会聊天的助手"，而是一个可以启动脚本、调用工具、访问网络、读取文件、写入配置的自动化执行体。
这时，安全边界就不能只停留在"提示词写得更谨慎""权限弹窗多问几次""分类器判断一下风险"这些层面。因为这些手段都属于应用层软边界，一旦恶意命令进入操作系统，子进程、脚本、构建工具、包管理器都可能继续放大风险。
沙箱系统的价值，就是把"能不能访问某个文件、能不能连某个域名、能不能写某个目录"交给操作系统级机制裁决。模型再聪明，也不能越过内核边界；提示注入再隐蔽，也不能凭一段文字偷走 SSH 密钥。
二、为什么权限弹窗还不够：真正的风险来自"命令已经跑起来之后"
很多人以为，只要每次执行命令前都让用户点一下确认，就足够安全。这个想法在早期还能成立，因为 Agent 能做的事情有限。但当 Agent 开始自动修复测试、自动安装依赖、自动搜索文件、自动运行脚本后，用户面对的是大量重复审批。审批越多，注意力越容易下降，最后就会变成"反正都点允许"。
权限弹窗的问题，不是它完全没用，而是它无法覆盖命令运行后的复杂行为。一个看起来普通的构建命令，可能会触发包管理器下载依赖；一个普通的测试命令，可能会执行项目脚本；一个普通的 Git 操作，可能会触发 hooks 或辅助进程。真正的风险，往往藏在"主命令之后的子行为"里。
因此，安全体系需要分层：模型侧判断意图，权限系统判断请求，分类器判断风险，而沙箱负责兜底。前几层可以犯错，但最后一层不能轻易被绕过。
|----------|----------|-------------|--------------|
| 安全手段 | 作用位置 | 优势 | 短板 |
| 提示词约束 | 模型生成前 | 成本低，能指导模型行为 | 无法强制约束系统调用 |
| 权限弹窗 | 命令执行前 | 用户可感知，可人工确认 | 频繁弹窗会导致审批疲劳 |
| 风险分类器 | 执行前判断 | 可自动放行低风险操作 | 误判时仍可能漏放危险动作 |
| 操作系统沙箱 | 进程运行时 | 强制限制文件与网络访问 | 需要配置白名单和平台适配 |
三、沙箱到底是什么：不是虚拟机，而是一圈进程级护栏
沙箱并不等于重新开一台虚拟机，也不一定需要完整容器。这里的关键思想是：让命令在一个受限制的进程环境里运行。它仍然可以执行开发任务，但只能在允许范围内读写文件、访问网络和使用本地资源。
对 AI Agent 来说，沙箱至少要解决两个核心问题：第一，不能让被诱导的命令随意读取主机敏感文件；第二，不能让命令随意向外部服务器发送数据。文件系统隔离解决"偷文件"，网络隔离解决"传出去"。两者缺一不可。
Anthropic 公开介绍过这套思路：Claude Code 的沙箱基于操作系统原语，把 Bash 工具运行在限定边界内；文件系统隔离默认只允许当前工作目录的读写边界，网络隔离通过代理控制出站域名，并在越界时通知用户确认。开源的 sandbox-runtime 也说明了它基于 macOS sandbox-exec、Linux Bubblewrap 和代理式网络过滤实现轻量级隔离。
四、双平台隔离架构：macOS 靠 Seatbelt，Linux 靠 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 安全系统必须首先识别平台，再选择合适的底层实现，而不是假设所有系统都一样。
|--------|---------------------------------|-----------------------|---------------------|--------------|
| 平台 | 底层机制 | 文件系统隔离方式 | 网络隔离方式 | 关键注意点 |
| macOS | Seatbelt Profile / sandbox-exec | 通过规则描述路径访问 | 代理 + 部分 Socket 路径控制 | 开箱可用能力更强 |
| Linux | Bubblewrap + 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 越自主，越需要硬边界；越能执行真实命令，越不能只靠提示词；越要进入企业生产环境，越必须具备配置锁定、审计、白名单和失败保护。
一句话总结：让模型自由发挥之前，先给它建一圈不会被提示注入轻易推倒的墙。
图12：AI Agent 沙箱安全体系收束图
参考资料：https://pan.baidu.com/s/1Fm6rZSZkY3q2NcrmTfTMeQ?pwd=6fkr