Docker 将 Sandbox Kit 规范捐赠给 CNCF，旨在标准化 AI 代理权限

Docker 宣布把 Sandbox Kit Specification 带到 CNCF，目标是让 AI 智能体可访问的内容像智能体本身一样可移植。这一宣布发生在 9 月 24 日的 WeAreDevelopers 活动上，规范采用 Apache 2.0 许可，目前版本为 v3。

要理解这个动作的分量，先要看它针对的现状。像 Claude Code、Codex 这类智能体会替用户安装软件包、调用 API、使用凭据，而让它们真正有用的那些授权——绑定挂载、宽泛的令牌、被打开的防火墙规则——通常散落在 shell 历史、控制台和人的记忆里，而不是存在于一份可审查的工件中。Docker 的论点是，这正是 OCI 当初被创造出来要防止的碎片化，否则每个运行时厂商都可能各自发明一套答案。

Sandbox Kit 的回应方式很直接：把一个智能体、它的工具以及一份带类型的请求清单（主机、凭据、卷）打包进一个普通 OCI 镜像。权限不再是一段口头约定或一份控制台配置，而是镜像内容的一部分。

v3 最值得注意的设计决定是“减法”。在 v3 中，Kit 不再是独立工件类型，没有自定义媒体类型，也没有 sidecar 文件，清单里只有一条声明 vnd.docker.sandbox.kit.descriptor。

这个取舍换来的是与既有工具链的兼容：Kit 可以用 docker buildx build 构建、用 docker pull 拉取，也能被扫描、签名或用在 FROM 中。更关键的是，固定摘要即同时固定内容与权限——镜像摘要一旦锁定，权限集合也随之锁定。

声明本身是带类型、带版本的能力，例如 com.docker.sandbox/network-policy@2 和 com.docker.sandbox/credential@1。规范给出的 GitHub CLI 示例展示了规则如何组合：Kit 允许访问 api.github.com，但拒绝 /repos/** 上的 DELETE，因为拒绝规则优先。凭据则可由代理托管——符合规范的运行时会向指定域名注入真实令牌，沙箱内只存在一个哨兵值。

代价同样明确：描述符语法与逐能力语义都是全新的，需要额外学习。既有注册表、扫描器和签名工具无需修改即可处理 Kit，但人要重新学一套表达方式。

这套设计里最容易被误读的一点是：Kit 只是请求权限，由宿主机决定。没有符合规范的运行时，该注解就是惰性的；如果某个必需请求无法满足，启动会被拒绝。

也就是说，镜像里写下的权限清单本身不构成任何强制力。它是一份可移植、可签名、可审查的意图声明，但把它变成实际隔离的是运行时。

Docker Sandboxes 在自带内核的 microVM 中运行智能体，是第一个符合规范的运行时。这里同时是这套方案当前最大的边界：符合规范的运行时数量只有一个，跨不同运行时的可移植性尚未得到验证。规范承诺的“像智能体本身一样可移植”，在运行时生态成形之前，仍是一个待检验的命题。

一次启动由一个提供根文件系统的工作负载 Kit 与任意数量的 mixin 叠加层组成。mixin 按 provides/requires 依赖图而非命令行标志顺序排序——顺序由依赖关系决定，不由人敲命令的先后决定。

解析规则是硬性的：若 requires 未满足，或两个 Kit 提供同名内容，解析失败。重叠声明会协调，网络规则取并集，不兼容的声明则报错。

更值得关注的是收敛机制：每个描述符都会归约为一份规范化的授权集合。可控制更新的运行时会记录该集合并阻止任何扩大它的版本——包括删除某条拒绝规则的版本。这一条把“权限只能收紧、不能悄悄放宽”从约定变成了可执行的检查。

需要区分两类信息。已确认的是规范本身的状态：Apache 2.0 许可、v3 版本、9 月 24 日的宣布、OCI 镜像承载权限声明、Docker Sandboxes 是第一个符合规范的运行时。

属于 Docker 自述、尚待第三方验证的有两项：其一，Docker 称规范附带两套一致性测试套件，一套针对 Kit 工件，一套针对运行时；其二，Docker 称它与 AWS、Box、Datadog、Dynatrace、JFrog、NanoClaw、OpenClaw、Palo Alto Networks 和 Snyk 等公司一起构建了 Kit。这两条在证据层面只能算来源主张，不能当作已核实的事实。

治理层面同样存在空白：报道未说明该规范是否已被 CNCF 某个项目接纳，也未说明会进入哪个成熟度级别。在治理变更之前，规范仍由 Docker 维护。

此外，Docker 鼓励就当前无法表达的 Kit 或运行时职责提供反馈，这本身说明规范的能力边界仍可能变化。

Sandbox Kit 的真正贡献不在于发明了新的权限模型，而在于把权限声明降格为普通 OCI 镜像的一部分，从而复用已有的构建、拉取、扫描、签名与摘要固定机制。这是一个务实的切入点：不要求生态先接受新工件类型，只要求它继续处理镜像。

但“可移植”目前只完成了一半。声明可以随镜像走到任何地方，强制力却只在符合规范的运行时里生效，而这样的运行时只有一个。在第二个符合规范的实现出现、跨运行时行为被实际验证之前，这套规范更准确的定位是一份设计良好、工具链友好、但尚未被生态验证的权限表达标准。

对工程团队而言，当下可操作的判断是：如果已经在用 Docker Sandboxes，Kit 提供了把权限纳入镜像审查流程的现实路径；如果依赖其他运行时，Kit 目前更像一份可读的意图文档，而非可依赖的隔离边界。