Docker 发布 Sandbox Kit 规范 v3,与 Linux Foundation 联手推为开放标准
Docker 把 Agent 权限声明做成了 OCI 镜像标准,权限 diff 能进 PR 审查,还能自动拦住偷偷扩权的版本升级,搞 Agent 工程的都该看看。
Docker 发布 Sandbox Kit 规范 v3,并联合 Linux Foundation/CNCF 将其推为中立开放标准,源码以 Apache 2.0 协议开源。v3 的关键变化是把 Agent 权限声明(网络规则、凭据、卷、工具、指令)打包成普通 OCI 镜像,可用 docker buildx 构建和 docker pull 拉取,registry 无需任何改动。规范将容器与沙箱区分开:容器共享宿主内核,而 Docker Sandbox 是独立内核的 microVM,边界位于模型能触及的一切之下。权限条目只作为请求存在,由宿主裁决,deny 优先于 allow,凭据由代理托管、真实值不进沙箱。规范还定义了自动化门禁,runtime 会逐版本比对权限集合,任何扩宽(如新版 Kit 偷偷删掉 deny 规则)都会被扣住询问。
Docker 发布了 Sandbox Kit 规范 v3,并联合 Linux Foundation/CNCF 将其推为中立开放标准。它把 AI Agent 运行所需的全部权限声明(网络规则、凭据、卷、工具、指令)打包成一个普通 OCI 镜像,让“Agent 被允许做什么”第一次变得可版本化、可审查、可复现、可跨运行时移植。 Docker Sandbox Kit Specification v3 github.com/docker/sandbox… 要解决的问题:Agent 的权限是“隐形积累”的 Agent 的每一项有用能力都来自一次授权,一个 bind mount、一个范围过宽的 token、一条为了省事而开大的防火墙规则。每一项单独看都合理,加起来就摧毁了隔离,而且全程不需要任何漏洞利用,漏洞就是配置本身。更糟的是这些授权没有落盘记录:它们散落在 shell 历史、控制台和人的记忆里,无法交接给同事、无法 diff 对比上周的版本。 核心洞察:容器打包应用,沙箱约束 Agent · 容器共享宿主内核,靠 namespace 和 cgroup 给一个“固定行为的工作负载”提供隔离视图,适合“拿到什么就只用什么”的软件。 · Agent 是概率性行为者:它自己决定下一步做什么并直接执行,会装需要 root 的包、开没人规划过的端口、第一条路被挡就换下一条。容器的边界恰好是它正在探测的同一个内核,这不可靠。 · Docker Sandbox 是 microVM,拥有独立内核,边界位于模型能触及或改写的一切之下。因此在沙箱内可以放心给 Agent root、放开限制,因为破坏止步于沙箱边界。 · 但空沙箱不是环境,还必须有东西声明:哪个 Agent 运行、配哪些工具和 MCP 服务器、哪些技能和指令塑造它、确切能碰什么。 v3 的关键设计:Kit 就是一个普通 OCI 镜像 这是本版本最重要的变化:Kit 不再是独立 artifact,而是标准 OCI 镜像,没有新 media type、没有 sidecar 文件、registry 无需学习任何新东西。 · 声明放在单一注解 vnd.docker.sandbox.kit.descriptor 中,内容放在镜像层里。 · 因此 Kit 天然可用 docker buildx build 构建、docker pull 拉取、被现有工具链扫描和签名、可作为 FROM 基础。锁定一个 digest 即同时锁定内容、权限声明和元数据,工具链和分发路径免费获得,需要学的只是格式本身。 · 两类 Kit:workload(运行并提供根文件系统,一次一个)和 mixin(叠加层:一个 CLI 及其网络规则、一个凭据绑定、Agent 上下文,可任意多个)。 可读的“权限条”:声明即请求,宿主裁决 1. Kit 自身不授予任何东西。每个条目都是“请求”(asks),由宿主决定是否满足。合规 runtime(实现规范描述的行为)会拦截不在白名单的主机;不合规的 runtime 里这个注解就是惰性的,只是一张没有执行的镜像。 2. deny 优先于 allow:能开 PR 的 token 删不了仓库。 3. 凭据是代理托管的:runtime 只向指定域名注入真实值,沙箱内只有一个哨兵,真实凭据不进沙箱。 4. 失败即拒绝启动:宿主无法满足的必需请求会导致启动失败,而不是让 Agent 以比声明更少(或更多)的权限跑起来。 组合是函数,不是序列 容器镜像从未解决多继承问题(Dockerfile 的 stage 只有一个 FROM)。Kit 的解法: · Mixin 按 provides/requires 声明的依赖图叠加,与命令行 flag 顺序无关,同一集合永远组合出同一镜像。 · Resolver 刻意严格:所有 requires 必须在集合内部满足,不为填补缺口去外部拉取;两个 Kit 提供同名能力直接报错而非静默遮蔽。 · 重叠声明有确定性的合并规则:网络规则取并集、hook 按依赖序执行、guidance 合成一份文档。不兼容的请求是错误,不是抛硬币。 · kind: set 描述符引用其他 Kit,在构建时运行同样的连贯性检查并合并成一个普通 Kit,不连贯的集合在你的构建时报错,而不是在别人的启动时。 Diff 即审查 + 不依赖人的第二道门 · 权限变化就是代码变化:当 Claude Code Kit 的下一版多要一个 host 或第二个凭据,这在 PR 里就是人类可以拒绝的新增行。 · 规范还定义了自动化门禁:每个描述符可归约为“宿主必须授予的规范化集合”;runtime 记录该集合并逐版本比对。范围内的更新可静默应用,任何扩宽都停下询问,包括删除 deny 规则(比如新版 gh Kit 偷偷去掉 DELETE /repos/** 的禁令,升级会被扣住)。这也解释了为什么声明必须长在 artifact 内部而不是旁边。 Docker @Docker Today at @WeAreDevs , Docker and the @linuxfoundation are announcing a collaboration around the Docker Sandbox Kit Specification: an open standard for declaring what an agent may do, where it may reach, and what it may touch. Open source under Apache 2.0. Read the deep dive: bit.ly/4rrcjql 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 0 👀 257 📊 1 ⚡