AI Agent 正在成为开发者日常中最强的生产力杠杆——但问题也随之浮现:一个能读写文件、调用 API、访问数据库的 Agent,跑在你的笔记本上,本质上已经拥有了"生产级"的权限。如果你的团队里每个人都在本地跑 Agent,谁来保证它们不会误删数据库、不会把密钥泄露到外部网络、不会调用不该调用的 MCP 工具?
Docker 的回答是:把笔记本当作生产环境来治理。 Docker AI Governance 正是为此而生——集中管控 Agent 的执行方式、网络可达范围、凭据使用边界,以及 MCP 工具的调用权限,让团队里每个开发者都能安全地跑 AI Agent,不管他们在哪里工作。
为什么笔记本成了新的"生产环境"
传统意义上,生产环境是远程服务器,有严格的访问控制、审计日志和网络隔离。而本地开发环境则相对宽松——毕竟只有你一个人在用。
Agent 改变了这个假设。当你给一个 Agent 配了数据库连接串、云平台 API Key、甚至 GitHub Token,让它自主完成任务时,这个 Agent 的权限边界已经和一台生产服务器差不多了。更关键的是:
- Agent 的行为不可预测:它可能根据 prompt 的不同,做出你没想到的操作路径。
- 多人协作放大风险:团队里 20 个人各自跑 Agent,权限策略碎片化,审计几乎不可能。
- MCP 工具是新的攻击面:Agent 通过 MCP(Model Context Protocol)调用外部工具,工具本身的安全边界谁来定?
Docker AI Governance 的核心思路:不限制 Agent 的能力,而是限制 Agent 的行为边界。 让 Agent 保持自主性,但在一个可控的"围栏"里运行。
四道围栏:Docker AI Governance 的管控维度
Docker AI Governance 提供了四个层面的集中管控:
1. 执行控制——Agent 怎么跑
定义哪些 Agent 容器可以启动、用什么镜像、以什么用户身份运行。你可以规定所有 Agent 必须使用公司审核过的基础镜像,禁止随意拉取陌生镜像。
2. 网络隔离——Agent 能访问什么
这是最关键的一道围栏。通过 Docker 的网络策略,你可以精确控制 Agent 容器能访问哪些网络端点。比如:允许访问公司内部 API,禁止访问公网;允许连接特定数据库,禁止连接其他服务。
3. 凭据管理——Agent 能用什么密钥
不再把 API Key 硬编码在 Agent 的配置文件里。Docker AI Governance 让你通过集中的凭据管理,决定哪些 Agent 可以访问哪些凭据,并且凭据本身不暴露给 Agent 的运行环境——它只能通过受控的通道使用。
4. MCP 工具权限——Agent 能调用哪些工具
MCP 是 Agent 连接外部世界的桥梁。Docker AI Governance 让你定义白名单:哪些 MCP 工具可以被调用,哪些工具的哪些方法被允许,哪些被禁止。
实战:用 Docker AI Governance 配置一个安全的 Agent 运行环境
下面是一个完整的示例,展示如何用 Docker Compose + AI Governance 策略,让一个 AI Agent 在本地安全运行。这个 Agent 可以访问公司内部 API 和指定数据库,但不能访问公网,也不能调用未经授权的 MCP 工具。
第一步:定义 AI Governance 策略文件
创建 agent-governance.yaml——这是整个治理策略的核心:
# agent-governance.yaml — Docker AI Governance 策略定义
version: "1.0"
governance:
# 执行控制:只允许使用审核过的 Agent 饶像
execution:
allowedBaseImages:
- "mycompany/ai-agent-runtime:1.2"
- "docker/ai-agent-base:latest"
runAsNonRoot: true # Agent 容器必须以非 root 运行
readOnlyRootFilesystem: true # 只读文件系统,防止 Agent 乱写
maxMemory: "512m" # 内存上限
maxCPU: "0.5" # CPU 上限
# 网络隔离:精确控制可达端点
network:
defaultAction: deny # 默认拒绝所有网络访问
rules:
- name: allow-internal-api
action: allow
destination: "10.0.0.0/8" # 公司内网 CIDR
ports: [443]
protocol: tcp
- name: allow-postgres
action: allow
destination: "db.internal.mycompany.com"
ports: [5432]
protocol: tcp
- name: deny-public-internet
action: deny
destination: "0.0.0.0/0" # 拒绝公网
ports: ["*"]
# 凭据管理:Agent 只能通过受控通道使用密钥
credentials:
allowedSecrets:
- "company-api-key" # 允许使用的 API Key 名称
- "db-connection-string" # 允许使用的数据库连接串
injectionMethod: env_mount # 凭据通过受控的环境变量挂载注入
denyHardcoded: true # 禁止在 Agent 配置中硬编码凭据
# MCP 工具权限:白名单制
mcpTools:
defaultAction: deny # 默认拒绝所有 MCP 工具调用
allowed:
- name: "github-mcp"
methods: ["search_repos", "read_file", "create_issue"]
# 明确允许的方法,create_pr 被故意排除
- name: "internal-docs-mcp"
methods: ["search", "read"]
- name: "postgres-mcp"
methods: ["query", "describe_table"]
# 不允许 drop_table、alter_table 等危险操作
注意:上面的 YAML 结构是基于 Docker AI Governance 公告中描述的四个管控维度(执行、网络、凭据、MCP 工具)设计的合理示例。具体字段名和格式请以 Docker 官方文档为准,发布时可能有所调整。使用前请对照最新文档修改字段名。
第二步:在 Docker Compose 中引用治理策略
# docker-compose.yaml
services:
ai-agent:
image: mycompany/ai-agent-runtime:1.2
governance: agent-governance.yaml # 引用治理策略文件
environment:
- AGENT_TASK=code-review
- MCP_CONFIG=/etc/mcp/config.json
volumes:
- ./mcp-config.json:/etc/mcp/config.json:ro
networks:
- agent-net
# 凭据侧车服务:受控地提供密钥
credential-proxy:
image: docker/credential-proxy:latest
governance: agent-governance.yaml
environment:
- SECRETS_SOURCE=vault # 从 Vault 拉取凭据
- SECRETS_LIST=company-api-key,db-connection-string
networks:
- agent-net
networks:
agent-net:
driver: bridge
internal: true # 内部网络,不暴露到宿主机外
第三步:配置 MCP 工具白名单
// mcp-config.json — Agent 的 MCP 工具配置
{
"mcpServers": {
"github-mcp": {
"command": "mcp-github",
"args": ["--repo", "mycompany/backend"],
"governance": {
"allowedMethods": ["search_repos", "read_file", "create_issue"]
}
},
"internal-docs-mcp": {
"command": "mcp-docs",
"args": ["--source", "https://docs.internal.mycompany.com"],
"governance": {
"allowedMethods": ["search", "read"]
}
},
"postgres-mcp": {
"command": "mcp-postgres",
"args": ["--host", "db.internal.mycompany.com"],
"governance": {
"allowedMethods": ["query", "describe_table"]
}
}
}
}
第四步:启动并验证
# 启动 Agent 服务
docker compose up -d
# 检查治理策略是否生效
docker compose exec ai-agent cat /etc/governance/status.json
# 验证网络隔离:Agent 应该无法访问公网
docker compose exec ai-agent curl -s --max-time 3 https://external-site.com
# 预期结果:连接超时或被拒绝
# 验证 Agent 可以访问内网 API
docker compose exec ai-agent curl -s https://api.internal.mycompany.com/health
# 预期结果:正常返回健康检查响应
治理不是限制,而是规模化前提
一个不受治理的 Agent,在个人手里可能是"很酷的工具";在 50 人团队里就是"不可控的风险源"。Docker AI Governance 的设计哲学很明确:
Agent 的自主性(autonomy)和安全性(safety)不是对立的。 治理策略定义了边界,边界之内 Agent 可以自由行动。这和 Kubernetes 的 NetworkPolicy、Linux 的 SELinux 是同一套逻辑——策略越精确,自由度反而越高,因为你知道哪些操作是安全的。
几个落地时的实际考量:
| 考量 | 建议 |
|---|---|
| 策略粒度 | 先从网络隔离和 MCP 白名单入手,这两项风险最高、收益最明显。执行控制和凭据管理可以逐步收紧。 |
| 团队推广 | 把治理策略文件放在团队共享仓库里,像代码一样做版本管理和评审。不要让每个人自己写策略。 |
| 调试体验 | 治理策略太严会导致 Agent 任务失败。建议先在 maxCPU/maxMemory 上留余量,网络规则用 allow 而不是 deny 覆盖内网,再逐步收紧。 |
| 审计日志 | Docker AI Governance 应该会提供 Agent 操作的审计记录。确保日志被收集到团队的 SIEM 或日志平台,这是事后追溯的唯一依据。 |
| MCP 工具更新 | 新的 MCP 工具不断出现。策略里的白名单需要定期评审——不是"加一次就不管了",而是像依赖升级一样持续维护。 |
上手清单
如果你准备在团队里引入 Docker AI Governance,建议按这个顺序推进:
- 盘点现有 Agent:列出团队里正在跑的所有 AI Agent,它们用了哪些凭据、访问了哪些服务、调用了哪些 MCP 工具。
- 写第一份策略:只覆盖网络隔离和 MCP 白名单,先不收紧执行控制。用上面的 YAML 模板改写。
- 在一个人身上试跑:选一个最熟悉 Docker 的开发者,用治理策略跑他现有的 Agent 任务,记录所有被误拦的操作。
- 调策略、扩范围:根据试跑结果调整策略,然后推广到整个团队。
- 接入审计:把 Agent 操作日志接入公司的日志平台,建立基线。
Agent 正在重塑开发者的工作方式,而治理决定了这种重塑能走多远。Docker AI Governance 把"笔记本即生产环境"这个现实变成了一个可管理的问题——不是要不要让 Agent 自主行动,而是如何在让它自主行动的同时,确保它不会越界。