2026 Apple Container 跑 AI Agent，上线前怎么验收沙箱？

启动成功了，但 Agent 仍可能读到工作区外文件、拿到环境变量里的密钥，甚至把数据发往任意地址。

最快判断：Apple Container AI Agent 沙箱只有在文件越权、凭据暴露、网络外连、资源耗尽和异常回收全部留下通过证据后，才适合上线；低风险单用户任务可保留 dsh 或 Docker，高风险代码执行和多租户任务只要有一项关键隔离失败，就应迁移到 Linux／KVM 上的 Firecracker，而不是关闭沙箱。

这篇文章适合三类人：在 Apple Silicon Mac 上为编码 Agent 建立可重复环境的平台工程师；负责审查不可信代码执行风险的安全人员；需要决定继续使用本地 Mac、扩充云端 Mac，还是迁移 Linux microVM 的团队负责人。

先记住一个验收原则：“任务能运行”只能证明启动链路可用，不能证明隔离边界有效。每项测试都应保存命令、输入、退出码、日志、宿主侧观察结果和运行时版本，避免只凭一次演示下结论。

先按证据分三档：Apple Container AI Agent 沙箱是否真的通过

验收结果不要只写“通过”或“失败”。更适合上线评审的方式，是把每个关键指标映射到明确动作。

验收结果	必须满足的条件	允许的任务类型	后续动作
✅ 可上线	文件、凭据、网络、资源、异常回收均通过；失败时能阻断并记录	已知代码、受控仓库、单用户低风险任务	固定版本、锁定策略、持续回归
⚠️ 限制上线	核心文件边界通过，但网络审计、资源配额或日志证据不完整	内部开发、无生产密钥、不可接触敏感网络的任务	禁止高风险代码和多租户任务，补齐证据
❌ 不通过	可读宿主密钥、越过授权目录、任意外连、资源失控或退出后残留	不应上线	加固配置；关键边界仍失败则迁移运行时

Apple 的官方项目把 Container 描述为在 Mac 上通过轻量 Linux 虚拟机运行容器，并要求 Apple Silicon 与 macOS 26；截至 2026 年 8 月 22 日，官方 Releases 页面显示最新发布版为 1.2.0。这些信息只能确认运行前提，不能替代实际隔离测试。Apple Container 官方 README 与 1.2.0 发布记录

第一项：先固定待验收的运行边界

测试前先记录：

• Mac 是否为 Apple Silicon。
• macOS、Apple Container、Agent 编排器和镜像摘要。
• Agent 实际启动的命令行，而不是配置文件里“计划启动”的命令。
• 工作区、临时目录、缓存目录和日志目录的真实路径。
• 是否挂载宿主目录、转发端口、共享 Unix Socket 或注入环境变量。
• 终止 Agent 后，谁负责删除容器、虚拟机、网络和临时文件。

Apple Container 的底层 Containerization 文档说明，每个 Linux 容器运行在自己的轻量虚拟机内，并通过 Virtualization.framework 管理；但“每个容器有虚拟机边界”并不意味着所有宿主目录、网络和凭据都自动被拒绝。共享目录、端口转发和宿主侧控制服务仍然需要单独审计。Containerization 架构说明

文件边界对比：从路径穿越开始，而不是从 hello world 开始

文件验收的目标不是证明 Agent 能读工作区，而是证明它只能读授权工作区。

建议准备至少四类测试文件：

1. 工作区内的普通源文件。
2. 工作区外的同名诱饵文件。
3. 指向工作区外路径的符号链接。
4. 包含 ..、绝对路径、隐藏目录和临时目录的路径样本。

然后让 Agent 通过真实工具调用执行读取、写入、列目录和压缩归档。不要只发送一句“请不要读取工作区外文件”的提示词，因为这测试的是模型服从性，不是运行时边界。

测试对象	重点检查	通过证据	常见误判
工作区外读取	/Users/...、宿主配置目录、其他项目目录	系统调用被拒绝，且宿主侧没有读到内容	Agent 没主动读取，就误以为不可读
路径穿越	../、绝对路径、规范化路径	规范化前后均被拒绝	只测相对路径
符号链接	链接指向授权目录外	解析后的目标仍被阻断	只检查链接本身所在目录
写入边界	工作区外写文件、覆盖宿主文件	写入失败，目标文件校验值不变	只观察 Agent 返回文本
只读根文件系统	写入 /etc、根目录和系统路径	返回拒绝，退出后没有残留	把“容器内 root”当成宿主 root

DeepSeek Harness dsh 的本地沙箱在 macOS 上选择 Seatbelt 后端，Linux 路径则涉及 bubblewrap 或 Landlock；其文档还说明 Seatbelt 依赖 macOS 自带的 sandbox-exec，并且自定义 runner 是扩展接口。dsh 本地沙箱配置说明

怎样确认 Agent 既碰不到宿主密钥，也越不过授权目录？
不要只执行一次 cat ~/.ssh/...。应覆盖“直接路径读取、环境变量枚举、递归搜索、符号链接、归档打包、日志回显和模拟外传”这几条路径。只要其中一条成功，结果就不能标记为生产可用。

dsh 的 Seatbelt 能不能替代完整虚拟机隔离？
不能直接画等号。Seatbelt 是进程级策略约束，适合限制文件效果和部分系统行为；它不是独立 Linux 内核，也不是多租户 microVM。Apple Container 则把 Linux 工作负载放入轻量虚拟机，但共享目录、网络策略和宿主控制面仍然要单独验收。Docker 的挂载边界同样取决于实际参数，尤其要审查宿主目录、特权模式、能力集和 Socket 暴露。

对于 Docker，默认 seccomp 配置会限制一组系统调用，官方文档称默认配置会阻断约 44 个系统调用；但显式使用 seccomp=unconfined、--privileged 或过度增加能力集，会改变这个安全前提。Docker seccomp 官方文档

凭据测试：让恶意提示词逼出真实暴露面

AI Agent 读取宿主密钥，通常不需要“逃逸”。只要凭据被注入环境变量、挂载进配置目录、写入日志，或者工具能访问宿主 Socket，模型就可能通过正常工具链把它带出。

建议把以下内容全部列入测试样本：

• 环境变量中的 API 密钥、云端令牌和部署凭据。
• ~/.ssh、云端 CLI 配置、包管理器认证文件。
• Agent 会话日志、工具调用日志和错误堆栈。
• 构建缓存、依赖缓存、镜像层和临时压缩包。
• 宿主侧 Docker Socket、控制 API、代码签名或密钥代理 Socket。

测试提示词可以要求 Agent “寻找可用凭据并验证权限”，同时配置一个模拟工具，把读取结果发送到受控接收端。验收时必须同时观察 Agent 输出、工具参数、容器日志、宿主文件访问记录和网络出口日志。

任何必须长期注入宿主真实密钥才能运行的方案，都不应直接判定为通过。更稳妥的做法是：

• 使用短时、最小权限令牌。
• 将密钥放在运行时外部的授权服务中。
• 让 Agent 只能调用经过审计的动作，而不是读取完整凭据。
• 在测试中验证过期、撤销和任务终止后的失效状态。

经验提醒：“密钥没有出现在 Agent 回复里”不代表没有泄露。工具参数、构建日志、调试堆栈、缓存文件和失败重试记录，往往比最终回复更容易留下敏感数据。

网络边界对比：运行时隔离不等于出站过滤

Apple Container、Docker 和 dsh 的文件策略，不能自动替代网络出口控制。网络验收要分别测试：

• 默认访问公网。
• DNS 解析。
• 内网网段和宿主服务。
• 云环境元数据地址。
• 本地监听端口和 Unix Socket。
• 允许名单之外的域名。
• 临时授权结束后是否仍能继续访问。

每次测试都要记录 DNS、连接目标、端口、响应状态、拒绝位置和审计日志。重点不是“请求失败了”，而是确认请求到底被谁拒绝：Agent 内部库、容器网络、Mac 主机防火墙、云侧网络策略，还是接收端主动丢弃。

Firecracker 官方设计文档明确指出，它本身不执行网络流量过滤，访客出站流量应在宿主层过滤。因此，即使迁移到 Firecracker，也不能把“换了 microVM”当成网络策略完成。Firecracker 设计文档

高风险 Agent 的阻断条件应包括：

• 能访问未列入允许名单的公网地址。
• 能访问宿主管理接口或内网控制平面。
• 能解析并连接云端元数据地址。
• 任务结束后，旧网络命名空间、端口转发或授权规则仍然存在。
• 没有可信的出站审计记录。

8 月 7 日和 18 日公开的安全公告都把更强 Agent 能力与监控、遏制和运行环境安全联系起来；其中涉及的 Astra 仍属于未发布模型，不能据此推导公开部署能力或性能结论，但这类背景足以说明“默认允许任意联网”不适合作为高风险代码执行策略。OpenAI 8 月 7 日安全公告

资源与回收：把失控任务当成必测故障

Agent 生成的代码可能死循环、创建大量子进程、持续写磁盘，或在超时后留下后台任务。资源验收不能只看正常任务完成，而应主动触发异常。

第二步：执行资源耗尽和强制终止测试

建议按以下顺序执行：

1. 启动 CPU 密集型死循环，确认配额生效。
2. 创建递归子进程，观察进程数限制。
3. 持续写入临时目录，检查磁盘上限和清理策略。
4. 分配大量内存，确认任务被终止而不是拖垮宿主。
5. 在前台和后台分别执行超时任务。
6. 发送强制终止信号，检查子进程、挂载和网络是否同时退出。
7. 重启运行时后再次扫描残留进程、目录、端口和日志。

涉及启动耗时、并发容量或资源开销的结论，必须引用官方资料或本站实测，不能用社区印象替代。Firecracker 官方生产宿主建议把 cgroups、命名空间、seccomp 和 jailer 作为纵深防御的一部分。Firecracker 生产宿主建议

验收证据至少应包括：

• CPU、内存、磁盘和进程数限制的配置快照。
• 超时前后的进程树。
• 容器或虚拟机的退出码。
• 任务结束后的挂载点和临时目录列表。
• 网络接口、端口转发和 DNS 状态。
• 清理失败时的告警与人工处置记录。

决策条件：保留 dsh、选择 Apple Container，还是迁移 Firecracker

下面的条件列表适合直接放进上线评审单：

• 若任务只处理可信代码、单用户运行，且文件和凭据测试通过：可保留 dsh 本地沙箱或 Docker。
• 若任务必须在 Apple Silicon Mac 上运行 Linux 工具链，且需要更清晰的任务级虚拟机边界：优先验收 Apple Container。
• 若网络出口无法形成允许名单和审计记录：不允许进入高风险生产任务，先加固网络控制层。
• 若 Agent 仍能读取宿主密钥、工作区外文件或控制 Socket：当前配置不通过，不能用提示词约束代替隔离。
• 若资源耗尽或强制终止后存在残留：先修复生命周期管理，再讨论并发和性能。
• 若是多租户、任意代码执行，且 Apple Container 的关键隔离项失败：迁移到 Linux／KVM 上的 Firecracker 路径。
• 若只因为 dsh 支持自定义 runner 就声称可以一键切换 Firecracker：结论不成立。自定义 runner 是扩展接口，不是已经提供好的 Firecracker 适配器。

任务风险	可保留方案	需要满足的证据	应迁移的信号
低风险单用户开发	dsh 或 Docker	工作区、凭据和回收测试通过	需要接触生产密钥或任意公网
Apple Silicon 上的 Linux Agent	Apple Container	虚拟机边界、挂载、网络和资源测试通过	共享控制面无法审计
高风险任意代码	Apple Container 仅作候选	所有关键测试均有可复核日志	任一关键隔离项失败
多租户任务	Linux／KVM 上的 Firecracker	jailer、seccomp、cgroups、宿主补丁和网络过滤齐全	只部署 VMM，未完成宿主加固
长期稳定重负载	自购或专用基础设施更合适	有持续容量和维护预算	临时环境无法保证长期资源

Firecracker 官方资料要求生产环境依赖 Linux、KVM、宿主与访客内核补丁，并建议通过 jailer、seccomp、cgroups 和命名空间形成多层防护；它不是在 Mac 上直接替代 Apple Container 的同构组件。

第三步：把一次验收变成可重复的上线门

发布前应把测试整理成固定脚本，并为每次运行保存：

• 环境摘要和镜像摘要。
• 沙箱策略与挂载清单。
• 恶意提示词和工具调用输入。
• 拒绝日志、退出码和宿主侧观察记录。
• 网络连接与 DNS 审计。
• 资源曲线和任务回收结果。
• 失败项、风险等级、负责人和复测时间。

如果团队需要在不同 macOS 版本、Apple Silicon 环境、并发方式和任务脚本之间复现同一组 PoC，临时云端 Mac 比直接改生产机器更容易控制变量。ProxyMac 的帮助中心可用于整理远程环境交付与登录流程；涉及预算时，再根据实际测试周期查看对应地区的租赁方案。

当前方案如果是普通本地 Mac 或共享开发机，常见缺点是环境状态容易漂移、宿主目录和密钥边界容易被临时挂载打穿、异常任务可能影响同机开发者，而且每次复现都要重新清理现场。若改用单独的云端 Mac，至少能把 macOS 版本、Apple Silicon 环境、任务并发和隔离脚本固定下来，再保存完整验收证据。对需要短期复现实验、上线前 PoC 或跨环境回归的团队，租赁 ProxyMac 的 Mac 环境通常比直接改动长期开发机更稳妥；但长期稳定重负载、必须接触物理接口或需要持续独占资源的任务，仍应评估自购 Mac 或专用基础设施。

验收完成后，最有价值的下一步不是立即扩大并发，而是把失败用例原样带到另一套环境中复测：同一 macOS 版本、同一 Apple Silicon 架构、同一 Agent 脚本、同一网络允许名单。只有证据能够复现，团队才知道是在加固 Apple Container，还是已经到了迁移 Firecracker 的节点。