AI Agent 不再只是调用一次模型 API。它可能读取代码、执行命令、访问网络，甚至操作云资源。Docker 宣布将 Sandbox Kit Specification 带入 CNCF，核心目标是让 Agent 的访问权限像 Agent 本身一样可移植：能够被打包、分发、版本化和审查，而不是散落在启动脚本、平台配置与人工约定里。
权限为什么也需要成为制品
今天部署 Agent 时，模型、代码和依赖通常已经可以通过容器镜像稳定交付，但权限配置仍然容易与运行环境绑定。例如，同一个代码审查 Agent 在开发机上可能可以读取整个仓库，在 CI 中只能访问检出目录，在生产环境中还需要限制外网域名和凭据目录。
如果这些规则分别写在 Shell 参数、Kubernetes YAML、平台控制台和安全文档中，就会出现几个问题：
- 难以复现：同一 Agent 在不同机器上获得了不同权限。
- 难以审计：代码版本可以追踪，实际生效的沙箱规则却不一定可以。
- 难以分发：团队共享 Agent 镜像时，还要额外传递一套平台专用配置。
- 容易漂移：应用升级了，权限策略却仍停留在旧版本。
Sandbox Kit Specification 所代表的方向，是利用 OCI 生态已有的镜像仓库、摘要、标签和供应链工具来携带权限声明。这样，Agent 与其沙箱策略可以分别演进，也可以通过不可变摘要绑定到一次部署。
需要强调的是：把权限声明装进 OCI 制品，不等于权限已经被强制执行。 OCI 负责包装与运输，真正的隔离仍然依赖运行时、操作系统、容器沙箱或云平台正确解释并执行策略。
OCI 化带来的工程变化
策略可以像镜像一样版本化
权限策略可以拥有语义化标签，也可以使用内容摘要固定版本。开发环境可以引用 dev 策略，发布流水线则应固定到类似 sha256:... 的摘要，避免标签被覆盖后静默改变权限。
审查对象从命令行参数变成显式清单
相比一长串启动参数，结构化策略更适合进入代码评审。安全团队可以直接检查文件系统、网络、进程和资源限制，而不必逆向分析多个部署脚本。
Agent 与权限可以解耦
同一个 Agent 镜像可以搭配不同策略：只读代码审查、允许执行测试、允许访问内部 API。反过来，组织也可以把一套基线策略复用于多个 Agent。
这种解耦也会带来新的版本兼容问题。运行时必须知道策略采用哪个规范版本；策略升级后，还要验证旧运行时会拒绝未知字段，而不是悄悄忽略它们。
可以这样做一个本地 OCI 权限制品原型
下面是一个说明性原型，用于展示如何把权限清单封装成 OCI 镜像。字段并不代表 Sandbox Kit Specification 的正式 schema，接入真实实现时应替换为规范定义的媒体类型、字段和运行命令。
先创建策略文件和 Dockerfile：
mkdir -p agent-sandbox-demo
cd agent-sandbox-demo
cat > policy.json <<'EOF'
{
"schemaVersion": "example/v1",
"filesystem": {
"readOnly": ["/workspace"],
"readWrite": ["/tmp/agent"],
"deny": ["/var/run/docker.sock", "/home/*/.ssh"]
},
"network": {
"allowDomains": ["api.example.internal"],
"denyPrivateRanges": true
},
"process": {
"allow": ["git", "python", "pytest"],
"deny": ["sudo", "mount"]
},
"resources": {
"memoryMiB": 1024,
"cpu": 2,
"timeoutSeconds": 300
}
}
EOF
cat > Dockerfile <<'EOF'
FROM scratch
LABEL org.opencontainers.image.title="agent-review-sandbox"
LABEL org.opencontainers.image.description="Illustrative permission policy for a code-review agent"
LABEL org.opencontainers.image.version="0.1.0"
COPY policy.json /sandbox/policy.json
CMD ["/sandbox/policy.json"]
EOF
docker build -t agent-review-sandbox:0.1.0 .
由于这是数据制品，而不是可执行应用，可以创建一个不会启动的容器，再取出策略进行检查：
container_id=$(docker create agent-review-sandbox:0.1.0)
docker cp "$container_id:/sandbox/policy.json" ./extracted-policy.json
docker rm "$container_id"
jq . ./extracted-policy.json
推送到仓库后，可以记录其不可变摘要：
REGISTRY_IMAGE="registry.example.com/security/agent-review-sandbox:0.1.0"
docker tag agent-review-sandbox:0.1.0 "$REGISTRY_IMAGE"
docker push "$REGISTRY_IMAGE"
docker buildx imagetools inspect "$REGISTRY_IMAGE"
运行时集成层可以先做最基本的版本与风险检查，再把策略交给真正的沙箱实现。下面的脚本只负责验证，不提供隔离能力：
#!/usr/bin/env bash
set -euo pipefail
POLICY=${1:-extracted-policy.json}
jq -e '.schemaVersion == "example/v1"' "$POLICY" >/dev/null
jq -e '.filesystem.deny | index("/var/run/docker.sock") != null' "$POLICY" >/dev/null
jq -e '.resources.timeoutSeconds <= 600' "$POLICY" >/dev/null
echo "Policy validation passed: $POLICY"
真实系统不能停在 jq 校验这一步。它还需要把声明映射到具体控制面，例如只读挂载、网络出口代理、seccomp、用户命名空间、资源限制或虚拟机级隔离，并在无法满足某条规则时默认拒绝启动。
落地时不要忽略这些边界
默认拒绝，而不是尽力而为。 如果运行时不认识某个权限字段，应拒绝策略或明确降级，不能静默放宽权限。
策略和 Agent 都要固定摘要。 只固定 Agent 镜像而继续使用可变策略标签，仍然无法完整复现部署。
签名不等于安全。 签名可以证明制品来自谁、是否被篡改，但无法证明规则本身足够严格。策略仍需静态检查和人工评审。
密钥不应写入策略制品。 清单可以声明允许访问哪个凭据接口，但真实令牌应由短期凭据系统在运行时注入。
网络域名许可并非万能。 DNS 重绑定、重定向、代理和共享域名都可能扩大实际访问范围。高风险 Agent 还需要出口代理、目标身份验证和请求审计。
采用前的检查清单
团队可以从低风险、只读型 Agent 开始试验，并确认以下问题：
- Agent 镜像和权限策略能否独立版本化并通过摘要绑定？
- 谁可以发布、签名和批准策略制品？
- 运行时遇到未知字段或不支持的限制时，是否会失败关闭？
- 文件、网络、进程和资源规则是否都有真实的强制执行机制？
- 每次运行能否记录 Agent 摘要、策略摘要和最终生效权限？
- 是否有阻止 Docker Socket、主机凭据目录和云元数据服务暴露的基线规则？
Sandbox Kit Specification 值得关注的地方，不只是新增一种配置格式，而是尝试把 Agent 权限变成供应链中的一等制品。只有当策略可携带、可验证，并由运行时可靠执行时，“同一个 Agent”在不同环境中才可能真正拥有一致且可审计的安全边界。