Docker 将 AI Agent 权限规范带入 CNCF：用 OCI 构建可移植的安全边界

2026-09-25 24 预计阅读时间: 1 分钟
来源: docker.com AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

AI Agent 不再只是生成文本。它们会执行命令、读写文件、访问网络，甚至调用企业内部服务。能力越强，权限边界就越重要。Docker 正在把开源的 Sandbox Kit Spec 带入 CNCF，希望以 OCI 为基础，将 Agent 权限描述发展为中立、厂商无关的开放标准。

这件事的价值不只是“又多了一份规范”。它试图解决一个更实际的问题：同一个 Agent 从本地开发环境迁移到 CI、Kubernetes 或云端沙箱时，能否携带一致、可审计的权限声明，而不必为每个平台重写一套安全配置？

Agent 权限为什么需要独立规范

传统应用通常拥有相对稳定的行为边界：Web 服务监听固定端口，批处理程序读取指定目录，数据库客户端连接已知地址。Agent 的行为更动态，它可能根据模型输出决定下一步动作，例如：

  • 执行模型生成的 shell 命令；
  • 读取工作区中的源代码和配置；
  • 向依赖仓库、搜索服务或内部 API 发起请求；
  • 创建临时文件或修改项目内容；
  • 调用浏览器、数据库、云平台 CLI 等外部工具。

如果权限只隐藏在启动参数、平台控制台或某个厂商的专有配置里，团队很难回答几个基本问题：这个 Agent 到底能访问什么？部署到另一套运行时后，限制是否仍然有效？安全审查看到的策略与实际执行策略是否一致？

开放权限规范的目标，是把这些边界变成机器可读、可版本化的声明。理想情况下，代码审查者可以像检查依赖和部署清单一样检查 Agent 权限，运行时也可以把声明转换为容器、虚拟机或沙箱的具体隔离措施。

OCI 带来的不只是镜像格式

OCI 已经为容器镜像、运行时和分发建立了广泛采用的基础。基于 OCI 设计 Agent 权限规范，潜在优势在于权限元数据可以与 Agent 使用的镜像、工具和其他制品进入同一条供应链：构建、签名、推送、拉取、验证和部署。

这并不意味着 OCI 本身会自动提供安全隔离。规范负责描述意图，真正的执行仍依赖底层运行时。例如，“禁止联网”最终可能被转换为容器网络设置、Kubernetes NetworkPolicy、微虚拟机规则或其他沙箱机制。

因此，落地时至少要区分三个层次：

  1. 声明层：Agent 请求哪些文件、网络、进程和系统能力；
  2. 转换层：平台如何把统一声明映射为本地安全控制；
  3. 执行层：容器运行时、内核、虚拟机或集群策略是否真正阻止越权行为。

厂商中立的规范主要改善前两个层次之间的接口。它不能代替 seccomp、Linux capabilities、只读文件系统、网络隔离或强身份认证。

先用现有容器能力建立最小权限基线

在正式规范和各平台实现逐步成熟之前，可以先用 Docker 已有的隔离选项验证自己的权限模型。下面的命令启动一个无网络、根文件系统只读、移除全部 Linux capabilities 的 Python 容器，同时只给 /tmp 提供有限的临时写空间：

docker run --rm \
  --network=none \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges:true \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  python:3.12-alpine \
  python -c 'from pathlib import Path; Path("/tmp/result.txt").write_text("agent sandbox ok\n"); print(Path("/tmp/result.txt").read_text())'

运行前需要安装 Docker。命令成功时会输出 agent sandbox ok。可以把最后的 Python 命令替换为自己的 Agent 入口，但要注意：如果它需要下载模型、访问 API 或写入工作区，就必须显式开放对应资源，而不是直接恢复全部权限。

例如，只向容器提供一个可读输入目录和一个可写输出目录：

mkdir -p input output
echo 'review this file' > input/task.txt

docker run --rm \
  --network=none \
  --read-only \
  --cap-drop=ALL \
  --security-opt=no-new-privileges:true \
  --mount type=bind,src="$PWD/input",dst=/workspace/input,readonly \
  --mount type=bind,src="$PWD/output",dst=/workspace/output \
  python:3.12-alpine \
  sh -c 'cat /workspace/input/task.txt > /workspace/output/result.txt'

cat output/result.txt

这里的关键不是命令本身，而是权限设计方式：输入只读，输出单独挂载，默认断网，不授予额外系统能力。即使 Agent 生成了危险命令，可造成的影响也会受到运行时边界限制。

可以怎样设计可审查的权限清单

下面是一个概念性示例，不代表 Sandbox Kit Spec 的正式字段或当前版本语法。它展示了团队可以如何把权限需求纳入代码仓库，并在未来适配标准化格式：

# agent-permissions.example.yaml
version: v1
agent: code-reviewer
filesystem:
  readOnly:
    - /workspace/source
  readWrite:
    - /workspace/output
network:
  default: deny
  allow:
    - host: api.example.internal
      ports: [443]
process:
  executables:
    - /usr/local/bin/python
    - /usr/bin/git
  shell: false
limits:
  cpu: "2"
  memory: 2Gi
  timeout: 300s

实践中，策略转换器应采取“无法映射就拒绝”的原则。假设某个平台不支持域名级网络白名单，就不应静默退化成允许全部出站流量，而应阻止部署或要求安全负责人批准替代方案。

权限文件还可以进入常规审查流程：

git diff -- agent-permissions.example.yaml

团队可以要求所有权限扩大都必须单独审批，例如新增可写目录、打开 shell、增加外部域名或延长执行时间。这样，Agent 行为的变化就不会埋在镜像更新或平台配置中。

采用时应重点检查什么

Docker 将规范带入 CNCF，释放出的重要信号是治理方向：Agent 权限不应长期被单一产品控制，而应允许运行时、云平台、安全工具和开发者共同实现。不过，进入云原生生态并不自动等于规范已经稳定，也不代表不同实现立刻拥有完全一致的安全语义。

评估和试点时，可以使用下面的清单：

  • 权限是否默认拒绝，而不是默认放行；
  • 文件、网络、进程和凭据能否分别授权；
  • OCI 制品与权限声明能否一起签名和验证；
  • 运行时无法执行某条限制时，是否明确失败；
  • 实际授权是否会生成日志并支持审计；
  • 策略升级是否可比较、可回滚；
  • Kubernetes、Docker 和其他沙箱后端之间是否有语义差异；
  • 密钥是否通过短期凭据注入，而不是写进镜像或策略文件。

更稳妥的采用路径，是先选择一个低风险 Agent，把现有权限写成显式清单，再通过容器参数落实最小权限。等规范和工具链成熟后，再将这份清单映射到标准格式。开放规范能够提升可移植性，但真正的安全仍取决于严格的默认值、可靠的运行时执行和持续审计。

# AI # Docker # LLM # 云原生

相关推荐