MCP Server 别直接跑在主机上:AI 工具也需要沙箱

昨天有个团队把 Git、数据库查询和浏览器自动化都接成 MCP Server，放进 AI 编程工具里试用。第一天大家觉得顺：问一句就能查仓库、改代码、跑任务。第二天安全同事只问了三个问题：这个 Server 是谁写的？它能读哪些目录？Token 泄露后能做什么？

这个问题比“会不会用 MCP”更早。MCP Server 一旦接到真实工具，就不再只是插件。它可能会读文件、访问内网、调用数据库、发起网络请求，甚至执行本地命令。如果直接跑在开发机或服务器主机上，很多权限边界会变得很模糊。

今天不讲 MCP 入门，只讲一件事：团队把 MCP Server 接进 AI 工具前，先用 Docker 把边界立起来。

MCP 的风险不在“协议新”

MCP 的价值很清楚：让 AI 应用用统一方式连接外部系统。文件、数据库、搜索、设计稿、浏览器、内部 API，都可以通过 Server 暴露给 AI 工具。

真正需要警惕的是，工具一旦接入真实系统，AI 工具的“建议”就可能变成“动作”。如果 Server 裸跑在主机上，常见风险会集中在四层：

层级	常见误区	更稳的做法
文件	直接挂整个 HOME	只挂项目目录，优先只读
网络	默认放开所有出口	按工具白名单放开
Token	共用个人账号权限	独立账号、最小 scope、短期凭据
镜像	临时拉取、版本漂移	镜像清单、固定 tag、上线前预检

Docker 不是万能安全方案，但它至少能先回答一个基础问题：这个 MCP Server 到底被允许碰哪里。

先把镜像和运行时排干净

很多团队第一次排 MCP Server，会直接盯配置文件。其实容器还没启动前，第一层就该查镜像来源和运行时版本。

docker pull docker.1ms.run/node:22-alpine
docker pull docker.1ms.run/python:3.12-slim
docker pull docker.1ms.run/redis:7

这一步不是把毫秒镜像（1ms.run）写成安全工具。它解决的是更基础的问题：Docker Hub、GHCR、MCR、Quay 等来源在团队网络里能不能稳定拉下来。镜像阶段先过，后面才值得继续查目录、网络、Token 和 scope。

Docker 沙箱要管住三件事

第一是目录。不要把整个用户目录挂进去，尤其不要让 Server 看到 SSH key、云厂商凭据、浏览器配置、历史下载目录。

第二是网络。文件类、Git 类 Server 不一定需要外网；数据库类 Server 也只需要访问指定数据库网络。默认全通，后面很难审计。

第三是权限。能用非 root 就不用 root，能只读挂载就不写入，能去掉 capability 就不要保留。

services:
  mcp-files:
    image: docker.1ms.run/node:22-alpine
    user: "1000:1000"
    read_only: true
    network_mode: "none"
    cap_drop:
      - ALL

这不是某个 MCP Server 的通用启动命令，只是边界示例。真正上线时，启动命令、环境变量、端口和网络都要按你的 Server 类型重写。

上线前用一张表过掉

检查项	必看问题
镜像	来源、tag、digest 是否记录
目录	是否只挂必要目录，是否默认只读
网络	是否能说明每个出口的必要性
Token	是否使用独立账号和最小 scope
日志	是否避免打印密钥、Cookie、连接串
审计	谁启用了哪个 Server，何时升级
回滚	上一版镜像和配置是否可恢复

这里的关键不是把 MCP 拦在门外，而是把它变成团队可控的工具。AI 工具越能干，越要让它在清晰边界里干活。

最后

MCP Server 值得做，它能把 AI Agent 从聊天框带到真实工作流。但团队落地时，别让它直接摸主机。先把镜像清单、目录挂载、网络出口、Token scope 和日志审计定下来，再接入 AI 编程工具。

这篇文章的结论很短：MCP 先关进沙箱，再谈效率。