在 AI Agent 逐步承担代码编写、文件操作、系统命令执行等敏感任务的今天，如何为这些智能体建立可靠的安全边界，成为工程团队必须正视的核心议题。与传统的微服务隔离不同，AI Agent 的行为具有高度动态性 ——LLM 会根据上下文自行决定调用哪些工具、访问哪些资源，这使得静态的权限模型难以适配。macOS 内核级沙箱方案 Seatbelt 提供了一种内核强制执行的细粒度约束机制，能够在系统调用层面拦截越权行为，为 AI Agent 的每一次工具执行提供可编程的安全围栏。
为什么选择 Seatbelt 而非用户态隔离
当前业界为 AI Agent 构建安全边界的主流方案包括容器隔离、虚拟机、以及用户态权限控制等。然而这些方案各有局限：容器虽然提供了进程级隔离，但容器逃逸漏洞在历史上屡见不鲜；虚拟机安全强度最高，但启动开销与资源消耗对于高频创建销毁的 Agent 执行环境而言过于沉重；用户态权限控制则依赖应用程序的自觉配合，无法阻止恶意代码绕过检查。相比之下，Seatbelt 作为 macOS 内核的安全机制，在每一次系统调用发生时进行策略校验，违规操作直接返回 EPERM 错误，进程本身对此毫无感知也无法规避。这种内核强制的默认拒绝模型，恰好契合了 AI Agent 安全设计的核心原则 —— 对未明确授权的行为一律说不。
Seatbelt 的策略检查发生在内核的 XNU 层，理论上任何通过系统调用与内核交互的行为都在其管控范围内。无论是直接的open、read、write操作，还是通过动态链接库间接发起的网络请求，抑或是 fork 创建的子进程，都必须通过 Seatbelt 策略的许可检查。这意味着即便 LLM 通过巧妙的 shell 技巧或库函数调用试图突破边界，内核层面的拦截都能确保这些尝试以权限错误告终，而非静默成功。
SBPL 策略语言的核心要素
Seatbelt 的策略配置文件使用 SBPL（Sandbox Policy Language）编写，这是一种基于 Scheme 的领域特定语言。尽管其语法继承自 LISP 家族，但日常使用的配置文件仅需掌握少数核心构造即可完成大多数安全策略的编写。SBPL 文件的基本结构包含版本声明、默认策略、以及一条或多条显式规则。版本声明为固定的(version 1)，默认策略使用(deny default)或(allow default)分别表示默认拒绝与默认允许，而具体规则则采用(allow OPERATION CONSTRAINTS...)或(deny OPERATION CONSTRAINTS...)的形式编写。
在 AI Agent 隔离场景中，最常用的操作类型分为三类：文件系统操作、网络操作、以及进程操作。文件系统操作的常用原语包括file-read-data、file-write-data、file-read*、file-write*，其中通配符形式匹配对应类型的全部子操作。网络操作则使用network-outbound和network-inbound分别控制出站与入站连接。进程操作中process-exec用于控制能否执行特定程序，process-fork则管理进程 fork 能力。
路径约束是 SBPL 中最丰富的过滤器语法。(literal "/exact/path")匹配精确路径；(subpath "/directory/")匹配指定目录及其所有子目录下的资源；(regex "^/pattern")则支持正则表达式匹配。这种多层次的路径指定方式，使得为 AI Agent 精确限定工作目录成为可能 —— 仅需将允许访问的路径集合声明为 subpath，将敏感区域明确排除在外即可。
AI Agent 沙箱配置的核心参数模型
为 AI Agent 设计沙箱策略时，应当遵循最小权限原则：默认拒绝一切行为，仅针对工作流程中确实需要的资源类型与路径逐一放行。一个典型的 AI 编码助手沙箱配置通常包含以下关键参数：
工作目录限定是最基础也是最重要的配置。通过(allow file-read* (subpath "/Users/developer/workspace/"))和(allow file-write* (subpath "/Users/developer/workspace/"))两条规则，Agent 被严格限定在指定的项目目录内活动。该目录之外的任何文件读取或写入操作都将被内核拦截并返回权限错误。这种设计确保即便 Agent 被诱导执行恶意操作，也无法触及用户的 SSH 密钥、浏览器配置、密码管理器数据等敏感资产。
可选的受限网络访问根据实际需求决定是否开启。若 Agent 工作流程仅涉及本地文件操作，则应完全禁用网络：network-outbound和network-inbound均不在 allow 规则中出现，所有网络请求将被拒绝。若确实需要访问特定服务，例如从私有 npm 仓库拉取依赖或向代码审查服务提交 patch，则应采用最严格的目标限定：(allow network-outbound (remote tcp "api.github.com:443"))将出站连接锁定在特定主机与端口组合，阻断对其他网络目标的探测与连接尝试。
进程执行控制同样需要精细配置。AI Agent 通常需要执行 git、npm、python、node 等工具完成开发任务，但这些工具本身也可能是攻击面。通过(allow process-exec (literal "/usr/bin/git"))逐一声明允许执行的二进制路径，可以防止 Agent 通过 fork+exec 系列调用启动任意程序。若需运行脚本解释器，则应配合路径限制确保其只能执行工作目录下的可信脚本，而非系统任意位置的 shell 脚本。
沙箱的执行与调试
完成策略编写后，通过sandbox-exec -f profile.sb <command>命令即可在指定沙箱配置下执行目标程序。对于 AI Agent 而言，通常需要将 Agent 调用的 shell 解释器、构建工具链、或各类 CLI 封装在沙箱内部 —— 即让sandbox-exec -f profile.sb bash -c "agent commands...""或sandbox-exec -f profile.sb /path/to/agent-runner成为 Agent 执行工作流的统一入口。
沙箱策略的调试需要借助系统日志。执行log stream --style compact --predicate 'sender=="Sandbox"'可以实时监控沙箱拦截事件，过滤特定应用名可进一步定位问题：log stream --style compact --predicate 'sender=="Sandbox" and eventMessage contains "python"'。当 Agent 报告权限错误或行为异常时，检查日志中 deny 条目对应的操作类型与目标路径，据此迭代调整策略规则。HackTricks 的 macOS Sandbox 文档提供了完整的基础原语列表，是编写复杂策略时的有益参考。
实践建议与工程参数
在生产环境中为 AI Agent 部署 Seatbelt 沙箱时，以下参数值得工程团队重点考量。首先是策略版本管理：将沙箱策略纳入版本控制，与 Agent 代码同步迭代，避免策略与实际需求脱节导致的功能破坏或安全漏洞。其次是动态策略生成：对于多租户或项目级隔离场景，可基于当前工作区路径动态生成 SBPL 配置文件，确保每个项目拥有独立的受限范围。
审计与告警机制同样不可忽视。建议对沙箱拦截事件采集度量，当特定时间段内拦截次数异常上升时触发告警 —— 这可能预示 Agent 被诱导执行了恶意操作或策略配置存在遗漏。最后是降级策略：尽管 Seatbelt 提供了内核级保护，但任何软件机制都存在失效可能。对于高敏感场景，应考虑在沙箱外围叠加容器隔离或网络层访问控制，构建多层次防御体系。
参考资料
- Apple Sandbox Guide（SBPL 语言参考）——https://www.romab.com/ironsuite/SBPL.html
- macOS Sandbox - HackTricks——https://angelica.gitbook.io/hacktricks/macos-hardening/macos-security-and-privilege-escalation/macos-security-protections/macos-sandbox
- sandbox-exec 命令行工具指南 ——https://igorstechnoclub.com/sandbox-exec/