正在打开每日关注
正在打开每日关注
Docker 联合 Linux Foundation 推出 Sandbox Kit 规范 v3,把 Agent 权限声明打包为普通 OCI 镜像,让权限可版本化、可审查、可复现。
Docker 发布了 Sandbox Kit 规范 v3,并联合 Linux Foundation/CNCF 将其推为中立开放标准。它把 AI Agent 运行所需的全部权限声明(网络规则、凭据、卷、工具、指令)打包成一个普通 OCI 镜像,让“Agent 被允许做什么”第一次变得可版本化、可审查、可复现、可跨运行时移植。 Docker Sandbox Kit Specification v3 https://t.co/GKHtfXEref 要解决的问题: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 内部而不是旁边。
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: https://t.co/meuAmgy5Ln
是什么 Docker 联合 Linux Foundation 发布的 Sandbox Kit Specification v3,Apache 2.0 开源,目标是用一个标准 OCI 镜像同时承载 Agent 运行环境(哪个 harness、哪些工具与 MCP 服务器、网络/凭据/卷权限、技能与指令)及其权限声明,让“权限”可版本化、可 diff、可复现。仓库是 Go 实现的规范核心包 + BuildKit 前端 + JSON Schema + 一致性测试套件,标注 experimental,目标 2026 Q4 定稿。
核心设计
Kit 无新 media type、无 sidecar:声明放 manifest 注解 vnd.docker.sandbox.kit.descriptor,内容放镜像层,锁定 digest 即同时锁定内容与权限,registry、扫描、签名工具链零成本复用。Kit 分两类:workload(唯一,提供根文件系统)与 mixin(零或多个叠加层),按 provides/requires 依赖图确定性组合,resolver 刻意严格(缺口报错、同名能力报错)。fail closed:未知字段报错,宿主无法满足的必需请求直接拒绝启动。
关键洞察 容器打包应用,沙箱约束 Agent——microVM 独立内核才能兜住概率性行为者;“Dockerfile 让软件可复现,Kit 让权限可复现”。deny 优先于 allow、凭据由 runtime 代理注入(真实值不进沙箱)、runtime 逐版本比对规范化权限集合,任何扩宽(包括删 deny 规则)都会被扣住。
坑与边界 Kit 自身不授予任何东西,非合规 runtime 下注解是惰性的;62 星的极早期仓库,第二家 conforming runtime 尚未出现,标准的实际采用与生态竞争仍待验证。