乐于分享
好东西不私藏
夜雨聆风 > > 办公文件 > 别让 MCP 乱调用工具:Docker AI Governance 给 Agent 加网络、凭据和白名单

别让 MCP 乱调用工具:Docker AI Governance 给 Agent 加网络、凭据和白名单

当前时间： 2026-08-12 08:04:27 分类：办公文件 评论(0)
别让 MCP 乱调用工具:Docker AI Governance 给 Agent 加网络、凭据和白名单

最近所有 AI 编程工具都在接 MCP。

Cursor 接 GitHub，Claude 接文件系统，Codex 接 Docker，VS Code 接数据库。看起来工具越多，Agent 越能干活。

但这里有一个很容易被忽略的问题：MCP 不是玩具插件，它是让模型能调用真实外部系统的通道。

一旦你把 GitHub、文件系统、数据库、浏览器自动化、云服务 API 都塞给 Agent，它就不只是“会帮你写代码”了。它也可能误删文件、误发请求、读取 token、把不该发出去的数据发出去。

Docker 这次推 AI Governance 和 MCP Toolkit，最值得看的不是营销词，而是一个很朴素的判断：Agent 真正危险的地方只有两条路径。

第一，它自己执行代码，碰文件系统和网络。第二，它通过 MCP server 调外部工具，替你操作真实系统。

管住这两条路，才算管住 Agent。

先别急着 Governance，普通人先用 MCP Toolkit

Docker AI Governance 更偏企业场景：管理员在控制台里定义策略，覆盖网络、文件系统、凭据、MCP tools，再把策略推到团队机器、CI 和云环境。

个人开发者今天更现实的入口，是 Docker MCP Toolkit。

官方文档里对它的定位很明确：用 Docker Desktop 管理容器化 MCP server，把它们放进 profile，再连接到 Claude Code、Codex、Cursor、Gemini、VS Code 等客户端。

这解决了 MCP 的第一个混乱点：不要让每个 AI 客户端各自跑一堆 server。

传统接法大概是这样：

text
1Cursor -> filesystem MCP2Claude -> GitHub MCP3Codex  -> Docker MCP4VS Code -> 另一个 filesystem MCP

每个客户端都有一份配置，每份配置都可能有 token、路径、命令。时间一长，你根本不知道哪一个 server 在跑、哪个 token 还有效、哪个项目暴露了哪个目录。

Docker MCP Toolkit 的思路是换成：

text
1Cursor / Claude / Codex / VS Code2              |3              v4        Docker MCP Gateway5              |6              v7    profile 里的容器化 MCP servers

AI 客户端只连 Gateway，MCP server 的生命周期、路由、认证和容器隔离交给 Docker 管。

最小实操：用 profile 隔离你的 MCP 工具

如果你已经装了 Docker Desktop，最小路径不复杂。

第一步，升级到 Docker Desktop 4.62 或更新版本。官方文档说明，MCP Toolkit 页面对应的是 4.62 及之后的界面。

第二步，打开 Docker Desktop 设置里的 Beta features，启用 Docker MCP Toolkit。

第三步，创建 profile。

不要所有项目共用一个 default profile。我建议按项目拆：

text
1profile: blog-writing2  - filesystem MCP: 只读 output/ 和 references/34profile: github-review5  - GitHub MCP: 只允许读 issue、PR、diff67profile: local-dev8  - filesystem MCP9  - Docker MCP10  - shell 类工具谨慎开启

第四步，从 MCP Catalog 里把需要的 server 加进 profile。遇到 Configuration Required 标记时，先补必填配置，不要跳过。

第五步，把 AI 客户端连到 Gateway。

如果客户端列表里没有你的工具，可以手动通过 stdio 接入：

bash
1docker mcp gateway run --profile my_profile

一个典型 JSON 配置长这样：

json
1{2"servers":{3"MCP_DOCKER":{4"command":"docker",5"args":["mcp","gateway","run","--profile","my_profile"],6"type":"stdio"7}8}9}

Codex 侧可以用下面命令确认状态：

bash
1codex mcp list

如果看到 MCP_DOCKER 是 enabled，说明客户端已经能通过 Gateway 调 profile 里的 MCP server。

Gateway 真正做了什么

Docker MCP Gateway 最关键的不是“统一入口”，而是把 MCP server 变成了可管理的运行时对象。

官方文档里写到，Gateway 会在隔离的 Docker 容器里运行 MCP server，并限制权限、网络访问和资源使用。AI 应用需要调用某个工具时，请求先到 Gateway，Gateway 决定哪个 server 处理；如果 server 没运行，就启动对应容器；然后注入必要凭据、应用安全限制，再把请求转发过去。

这比你在本机裸跑 node server.js 或 python mcp_server.py 稳太多。

裸跑 MCP 的问题有三个：

  1. 依赖污染：每个 server 都要装 Node、Python、包管理器和一堆库；
  2. 权限过大：server 往往继承当前用户权限，能读到很多不该读的目录；
  3. 不可审计：你很难复盘某次 Agent 到底调用了哪个 server、传了什么参数。

Gateway 至少把这些东西收束到一个 chokepoint。所有工具调用先过这里，才有机会做认证、授权、日志和策略。

这也是 Docker AI Governance 的底层逻辑。

Governance 管的是四个控制面

Docker 官方博客把 AI Governance 的控制面拆成四类：网络、文件系统、凭据、MCP tools。

这四个词很朴素，但正好覆盖 Agent 失控时最常见的事故。

1. 网络

Agent 能不能访问公网？能不能访问内网 IP？能不能请求某个生产 API？

如果你让 Agent 一边读客户数据，一边能随便访问外部 URL，本质上就是给了它一条数据外流路径。

企业级 Governance 可以用 allow/deny 规则控制域名、IP、CIDR。个人用户虽然未必有控制台，但至少可以通过 Docker 网络、代理和 profile 把不同项目的工具隔开。

2. 文件系统

Agent 能挂载哪些目录？只读还是读写？

这是个人开发者最容易翻车的地方。很多 filesystem MCP 教程一上来就让你开放整个 home 目录。这样确实省事，但也等于把 SSH key、浏览器配置、历史项目、备份文件都暴露给了模型工具链。

更合理的做法是：每个项目只挂载当前 repo，能只读就只读，需要写入再给写入。

3. 凭据

Agent 的危险程度，取决于它能拿到什么 token。

GitHub token、Docker Hub token、云厂商 AK/SK、数据库连接串，只要进入 MCP server 或客户端配置，就必须假设模型有机会间接触达它们。

Docker AI Governance 的企业方案会控制哪些凭据能被 Agent session 看见，并限制生命周期。个人用户至少要做到两点：不要把 token 写进 prompt，不要把 MCP 配置提交到 Git。

4. MCP tools

不是所有工具都应该对所有任务开放。

写文章时，Agent 可能只需要读文件和检索资料；修 bug 时，可能需要 GitHub 和测试命令；部署时才需要 Docker 或云服务。

最好的工具策略不是“全都接上”，而是按 profile 拆小集合。

text
1写作 profile：filesystem(read-only) + web/search2代码 review profile：GitHub(read) + filesystem(read-only)3本地开发 profile：filesystem(rw) + Docker + test command4生产运维 profile：默认不要给 Agent

工具越少，模型越不容易误选，出事后也更容易定位。

🚨 踩坑提醒

第一，Docker AI Governance 更偏组织级产品，不要把它写成个人用户点几下就能完整拥有的免费功能。个人能马上落地的是 Docker MCP Toolkit、profiles 和 Gateway。

第二，MCP 配置里经常有 token、路径和命令参数。无论是 Cursor、Codex 还是 Claude 的 MCP JSON，都应该进 .gitignore，不要上传公开仓库。

第三，不要一次暴露几十个 MCP server。工具太多不是能力强，而是决策噪声变大。先给 Agent 最少工具，确认任务跑通，再补新工具。

给个人开发者的一套默认方案

如果你只是个人开发者，今天最值得抄的是这一套：

  1. Docker Desktop 开启 MCP Toolkit；
  2. 每个项目单独建 profile；
  3. 文件系统 server 默认只读；
  4. GitHub token 只给最小权限；
  5. Codex/Cursor 统一通过 docker mcp gateway run --profile xxx 接入；
  6. 所有 MCP 配置文件加入 .gitignore；
  7. 生产数据库、生产部署、云厂商高权限 token 暂时不要给 Agent。

这套方案不会让你的 Agent 突然变聪明，但会让它更可控。

AI 编程工具接 MCP，是为了让模型能干真实工作。

但真实工作一定伴随真实权限。

我现在更愿意把 MCP 看成一组“临时发放的工牌”，而不是一串永久钥匙。每个任务只发它需要的那张，干完就收回。Docker 的 MCP Toolkit 和 Gateway，至少给了我们一个能开始这样管理的入口。

素材来源：

  • Docker AI Governance 官方博客：https://www.docker.com/blog/docker-ai-governance-unlock-agent-autonomy-safely/
  • Docker MCP Toolkit 入门文档：https://docs.docker.com/ai/mcp-catalog-and-toolkit/get-started/
  • Docker MCP Gateway 文档：https://docs.docker.com/ai/mcp-catalog-and-toolkit/mcp-gateway/

#Docker #MCP #AIAgent #Cursor #Codex #工具调用