最近在几个开发者社群里讨论 MCP 配置我发现一个规律大家聊“怎么接入 MCP Server”特别积极但一提到“Secret 怎么放、Shell 命令能不能执行、Remote MCP 到底要不要开”群里一下子就安静了。这个现象不怪谁因为 MCP 本身看起来就是个“配置文件 启动命令”的事很多人配通就跑根本没想到要给 AI 工具划定权限边界。这篇文章把我这段时间在本地环境、容器和一台测试服务器上做的 MCP 安全检查实测整理出来覆盖 Secret 管理、Shell 类工具、Remote MCP 暴露面以及最终的权限边界配置方法适合正在用 Claude Code、Cursor、Trae 等 MCP 客户端又担心被 AI 工具或恶意配置搞出事情的开发者。1. MCP 配置安全检查的边界在哪1.1 先弄清楚 MCP 的信任模型才知道哪些位置要防守MCPModel Context Protocol本质上是一个 JSON-RPC 通信协议它把 AI 客户端比如 Claude Code、Cursor、Trae甚至自己写的命令行工具和 MCP Server 连起来。Server 通过“工具”暴露能力客户端通过自然语言让模型决定调用哪个工具。这个模型里有一个很容易被忽视的事实一旦 MCP Server 进程启动起来它可能拥有和你当前用户一样的文件读权限、网络访问权限甚至执行命令的权限。很多 MCP 只需要一行 npx 命令就能拉起来比如npx some/package mcp-server那这个包里的任何代码都能在启动时运行它能读你的密钥、写你的目录、访问内网服务。用大白话讲MCP 的信任边界就是“运行该 Server 的用户权限边界”配置得越随意暴露面就越大。1.2 一份检查清单从配置到运行时的五个维度做了几十次实测之后我把 MCP 安全检查拆成五个维度分别是我在配置阶段会逐一排查的第一是配置文件本身的访问控制看谁有权限读取和修改这些 JSON、TOML、env 文件第二是 Secret 的存放与传递方式token 有没有被放进明文配置或者被不合适的进程读到第三是 MCP Server 暴露出来的能力范围尤其是 Shell 这类可以执行命令的工具第四是网络暴露面特别是 Remote MCP 开启后是否可被公网访问第五是依赖链风险启动 MCP 的 npm 包或 PyPI 包是否可信。这五个维度里面前四个会直接影响普通开发者的日常使用第五个更多是供应链审计问题这篇文章先重点展开前四个。1.3 我建议的检查顺序我的检查顺序是从外到内先查启动命令看有没有把 Secret 写进去再查 Server 以什么身份运行是 root 还是普通用户然后看它监听哪些端口是 stdio 还是 TCP接着读一下 Server 的配置确认哪些工具被开放最后我会在测试环境里跑一遍最小调用用无害命令验证真实权限边界。这个顺序的好处是能在不深入了解每一个 Server 内部逻辑的情况下快速判断风险最集中的几个点如果某一步就发现明显问题后面就不用继续浪费时间去跑了。2. Secret 管理实测从明文配置到最小暴露2.1 三种常见的密钥存放方式风险等级完全不同实际排查过十几个 MCP 配置之后我总结出三种最常见的 Secret 存放方式。第一种是直接写在 MCP Server 的配置 JSON 里例如给 Claude Code 配置远程 MCP 时在env字段里写OPENAI_API_KEY: sk-xxx这种写法最危险因为配置文件很容易被同步工具、git 仓库或截图带出去。第二种是写进.env文件再在启动命令里用类似env $(cat .env) mcp-server的方式引入比直接写 JSON 好一点但.env文件一旦权限设置不对同机用户照样能读。第三种是把密钥交给系统密钥管理器比如 macOS Keychain、Windows 凭据管理器或 Linux 的 Secret Service由 MCP Server 在需要时通过 API 读取配置文件里只写一个引用名。我在 Windows 和 macOS 上都试过这种方式安全性最好但配置成本也最高而且不少 MCP Server 本身并不支持这么读需要你写一层封装脚本。2.2 实测chmod 到底能不能挡住不该看的人我专门在一台多人使用的 Linux 开发机上做了组权限测试。先把配置文件和.env设为chmod 600目录设为chmod 700结果同组用户用cat直接报 Permission denied这是符合预期的但我故意把目录权限改成755、文件权限保持600这时候同组用户虽然不能直接打开文件却可以通过ls -la .env看到文件名还能通过文件描述符、shell 历史等旁路方式嗅探到一些信息。更隐蔽的是如果 MCP Server 是用 systemd 服务方式启动的服务配置里的EnvironmentFile指向目录可能带有默认的 644 权限子进程虽然继承了密钥但日志和/proc/pid/environ里也都能看到。所以我的实测结论是文件权限只是第一道锁还要配合密钥轮换、日志脱敏以及尽量不让密钥以明文形态长时间留在磁盘上。2.3 那些容易被忽略的 Secret 泄露路径有一类泄露路径特别容易翻车就是 AI 上下文本体。MCP Server 在请求模型回答时会把工具返回内容拼进上下文如果某个工具把环境变量、配置内容或启动参数返回给模型而这些内容里恰好有 Secret密钥就相当于跟着对话记录走了一遍可能被记录在日志、会话历史或远程服务端。我在自己写的一个 MCP Server 里特意加了一个返回 env 变量的调试工具然后让 Claude Code 调用它结果整个 KEY 出现在客户端日志里才意识到这个问题的严重性。处理办法有两个一是给 Server 的返回内容加脱敏识别sk-、AKIA、ghp_这类前缀并替换成占位符二是在客户端侧设置日志级别不输出完整请求体响应体。顺带一提像蓝湖 MCP 这类设计协作工具接入时也要同样处理token 同样要放进受限环境变量别因为对方是官方库就放松警惕百度智能云这类云平台在获取 Secret Key 时页面只会完整展示一次复制下来之后如果不及时收进密钥管理器后面再想找回只能重新生成这也是很容易被忽略的时间窗。2.4 多客户端共用 MCP 时的密钥隔离一个更现实的场景是同一台电脑上同时装了 Cursor、Trae、Claude Code几个客户端都想接同一个 MCP Server很多人图省事就在全局配置里写了一份密钥让所有客户端共用。这个做法问题很大因为不同客户端的配置目录权限、默认同步行为都不一样其中一个客户端把配置同步到某个插件市场或远程回放后密钥就跟着出走了。我的做法是给每个客户端单独建一份.env文件分别配置不同的 Token服务器端也只发只读或最小能力的密钥不给一个万能 Token。这样某个客户端被拖库或者同步到不该去的地方你只需要吊销那一份 Token不用整个项目迁移。审计的时候也更清楚哪个客户端在什么时候调用过服务出了事不至于连源头都找不到。3. Shell 类 MCP 工具的权限边界实测3.1 Shell MCP 到底开放了什么能力Shell 类的 MCP Server 非常多行为也几乎都一样提供一两个工具用来执行 Shell 命令或脚本。我见过最激进的高级别封装甚至给了run_script、execute_python、run_bash、list_processes好几个工具每个都能做不少事情。要明白一个前提AI 模型本身没有“判断该不该执行”的能力它只是在用户输入的上下文中选择工具调用只要调用关系成立命令就会在 MCP Server 所在进程的权限范围内执行。如果这个 Server 是用 root 启动的Agent 决定执行破坏性命令它就真的会把事情干了如果是在普通用户容器里破坏范围就小很多。这也是为什么我一直强调Shell MCP 的权限边界不是靠模型自觉而是靠底层运行环境和配置项硬性圈出来的。3.2 实测三条防线叠加后的真实效果我搭了一套测试环境写了一个支持--allowed-commands和--working-dir参数的 Mini Shell MCP Server然后分别用三种方式跑。第一种是普通用户直接在本机跑只允许ls、pwd、cat结果调用删除命令时 Server 直接返回工具权限不足第二种是允许bash -c但把工作目录限制在一个临时目录里命令被成功执行但最后发现它无法读取项目目录外的敏感文件第三种是放进 Docker 容器用下面这个启动参数来跑。docker run --rm -i --read-only --tmpfs /tmp \ -v /workspace:/workspace:ro \ mcp/shell-server \ --allowed-commands ls,cat,pwd \ --working-dir /workspace这条命令的效果值得拆开讲一下。--read-only把容器的根文件系统设为只读AI 即使想往系统目录写文件也会失败--tmpfs /tmp单独给临时目录一个可写空间满足正常跑脚本的需求又不污染镜像/workspace以只读方式挂载进来等于告诉 Agent 这个目录只许看、不许改。加上--allowed-commands的白名单相当于在“配置层、系统层、容器层”三个层面同时设卡。实测中 AI 调用cat /workspace/notes.txt可以正常返回调用ls ~时因为/workspace之外没有挂载任何宿主目录只能看到空目录调用删除命令则因为只读挂载被拒绝。整个过程我特意多跑了几遍确认不是模型“自己选择不执行”而是底层确实拦住了。3.3 路径边界和能力边界两个都要定很多人配 Shell MCP 只设置允许的命令不设置允许的路径这等于只锁了门但没锁窗。比如工具允许catAI 就能读cat ~/.ssh/id_rsa再把内容返回给你这不算“越权执行”但就是信息泄露。我建议强制配置--allow-dir或--deny-dir把 Server 能访问的目录限定到项目目录如果有读取系统配置或密钥文件的需求再用单独的工具去对接而不是把所有路径都交给通用cat。另一个容易被忽视的是工具描述信息MCP Server 在工具描述里如果写了“执行任意 Shell 命令”AI 就会认为所有命令都可以调用如果你在描述里明确“仅用于项目内文件操作禁止执行删除和写入系统目录”模型在决策时会更保守。实测下来描述对行为的影响比我预想的大得多建议大家在封装工具时把描述写窄一点。3.4 工具描述是 AI 侧最容易忽略的权限开关MCP 协议里每个工具都有description字段很多人习惯随便写一句话但这个东西对 AI 的决策影响极大。模型在决定调用哪个工具时会结合工具名称和描述去匹配当前任务描述里写“execute any command”和写“list files in workspace”同样的底层函数会带来完全不同的调用行为。我做过一个对比实验同一个 Shell MCP Server第一版工具描述写得很宽泛AI 收到“清理临时文件”的指令后真的执行了rm -rf /tmp/*第二版我把描述写成“仅展示项目目录下的文件列表拒绝删除类操作”再跑同一个指令时模型明显更倾向于先列出文件让你确认而不是直接动手。这个现象说明权限边界不只是在系统层模型侧的语义约束同样能起到“软隔离”的作用。当然软隔离不能替代硬隔离但两者叠加使用出事的概率会低很多。4. Remote MCP 的安全暴露面实测4.1 为什么 Remote MCP 一开就会被扫MCP 标准模式是 stdioServer 和客户端在同一台机器上通过标准输入输出通信。但实际工作里很多人喜欢把 MCP Server 跑在一台性能更好的服务器上让开发机通过 Remote MCP 去连或者让团队共享同一个 MCP Server。这时候就要把 MCP 从 stdio 切换到 HTTP 或 SSE最省事的做法就是监听0.0.0.0:8888然后告诉同事“连这个地址就行”。我有一台测试用的云主机专门拿来做过一次无鉴权 Remote MCP 暴露测试结果让我印象很深监听公开端口后不到两小时日志里就出现了大量来自不同 IP 的 JSON-RPC 请求有的在尝试握手有的直接拉取工具列表有的在发一些探测性质的 tool call。这说明互联网上那些扫描器对 MCP 端口早就不是陌生面孔了只要端口暴露就一定有自动化程序来敲门根本不需要被谁针对。4.2 远程 MCP 的四道防线缺一不可如果你确实需要把 MCP Server 暴露到网络上我建议按下面四道防线来加固。第一是传输层至少使用 HTTPS 或 WSS绝对不要用 HTTP 明文传输因为 MCP 交互里很可能带着文件内容、数据库查询结果甚至 Secret第二是应用层鉴权必须加 Bearer Token最好支持定期轮换用curl -H Authorization: Bearer ${MCP_TOKEN}这样请求如果有条件mTLS 比 Token 更可靠毕竟证书不容易被复制但配置复杂度也高。第三是网络层白名单用防火墙把来源 IP 限制到固定的开发机或办公网段公网其他来源一律拒绝第四是监听地址如果所有人都在局域网内那就监听内网 IP 即可不要暴露公网如果只有你自己用最佳方案是监听127.0.0.1然后用 SSH 隧道转发。ssh -N -L 127.0.0.1:8888:127.0.0.1:8888 userremote-box上面这条 SSH 隧道命令是我在远程开发场景里最常用的一种做法。它在本地机器上建立一条到远端服务器的加密连接并把远端127.0.0.1:8888映射到本地的127.0.0.1:8888这样 MCP 客户端只要连本地端口就能访问远程 Server而 Server 本身始终只监听回环地址公网扫描根本扫不到。SSH 的认证由系统级的密钥机制管理密钥比自定义 Token 容易维护得多连接内容也全程加密。这个方案唯一的门槛是要求每个人都能 SSH 到那台机器但这对开发团队来说本来就是基本功所以实际实施成本远低于搭一套完整的 OAuth 基础设施。注意SSH 隧道只是让访问路径加密且不暴露端口Server 自身的鉴权和工具白名单仍然要配不能因为用了隧道就把 Token 去掉。4.3 实测不同鉴权形态下的扫描响应我顺手记录了一组对比数据。无鉴权暴露时任何来源发送一个合法的 JSON-RPCinitialize请求都会得到完整的 Server 信息响应扫描器能立刻确认这是一个 MCP 端点加了固定 Token 后同一请求会返回 401 或 403扫描器大概率放弃但如果 Token 不小心放在 npm 脚本、日志或浏览器历史里被扒出来之后就和没加一样做了网络白名单之后非白名单 IP 在 TCP 层就被拒了连 HTTP 握手都到不了 MCP 服务。实测下来最让我安心的是“监听回环地址 SSH 隧道”的组合因为在网络层根本看不到这个端口没有任何扫描日志产生。这里也想提醒一句任何远程服务的安全都不该依赖“没人知道地址”只要地址外传过就必须当作暴露过一样对待密钥该轮换就轮换白名单该收紧就收紧。4.4 Remote MCP 的日志与审计要点Remote MCP 一定要留日志而且要留结构化日志。我见过不少同事把 MCP 日志关掉理由是“太吵”结果真出问题的时候连谁调用过工具都查不到。建议至少记录四个字段时间戳、来源 IP、调用的工具名、是否放行。下面是一个我常用的 JSON 日志行示例。{ts: 2025-01-08T14:23:11Z, peer_ip: 10.0.0.4, tool: read_file, allowed: true}这样一条日志能帮你回答很多问题这个 Remote MCP 是不是被陌生 IP 扫过哪个客户端在凌晨两三点还在批量拉文件哪个工具被频繁拒绝调用如果发现allowed: false大量出现说明有请求在撞你的白名单要么是配置给少了要么就是有人在探测。日志本身也是敏感信息不能把请求体、响应体或 Secret 字段写进去否则日志文件泄露就等于密钥泄露。我一般把日志写到独立目录权限设为600由 logrotate 定期轮转既保留排查能力又不至于占满磁盘。5. 权限边界配置清单与常见排查实录5.1 一套可以直接抄的权限边界模板前面讲了很多原则这里给出一套我在本地开发机上实际使用的配置模板你可以直接参考。本地配置文件放在~/.config/mcp/下目录权限设为700每个 Server 的配置文件和.env都设为600启动 MCP Server 时统一用一个mcp-run.sh脚本读取.env禁止在命令行里直接传密钥参数能容器化跑的工具一律用容器挂载目录只读运行用户不要用 root需要网络访问的 MCP全部绑定127.0.0.1只有必须提供给团队共用的才走白名单加 Token。AI 客户端那边我在 system prompt 里加了一条约束要求它在工具返回敏感信息时用占位符描述不输出明文。整套模板用下来最明显的变化是更换开发机时配置迁移更轻松因为密钥不在配置文件里搬走配置本身并不会有泄露风险。5.2 常见问题速查表把这段时间遇到的高频问题整理成了一张速查表方便大家排查时直接对照。现象最可能的原因排查思路MCP 启动报错找不到 API KeySecret 没有正确注入到进程环境变量先看启动脚本里有没有 source.env再看 Server 是否支持环境变量名远程 MCP 一直连不上监听地址绑定错误或防火墙限制在服务器上curl http://127.0.0.1:8888测本机连通性再检查安全组/UFWToken 出现在命令历史里启动命令直接写了 Token 参数立刻轮换 Token修改启动脚本用环境变量文件替代容器内 MCP 读不到宿主文件挂载卷没有映射或权限受限检查 docker-v参数确认挂载路径和读写模式AI 突然拒绝执行普通命令Shell MCP 的白名单配置过严查看 Server 日志确认是哪个工具被拦再按需放宽范围而不是直接放开所有命令日志文件里出现敏感 KeyServer 没有做日志脱敏增加脱敏过滤调低日志级别优先清理历史日志5.3 关于权限边界容易混淆的两个概念第一个概念是“权限边界是叠加的不是替代的”。AI 侧的提示词约束不能替代系统层的权限限制容器隔离也不能替代工具白名单。你可以在 system prompt 里写一万遍“不要删除文件”但模型一旦被 prompt injection 引导照样可能发起危险调用反过来即使容器根文件系统只读如果你把宿主目录可写地挂载进去容器内的破坏照样能污染宿主的业务数据。每一层防线只解决它那一层的问题不要指望一个单点措施就能搞定全部安全。第二个概念是“只读不代表无风险”。有些文件只读照样是敏感信息比如~/.ssh/id_rsa、.env、云平台密钥文件只要工具能读取就可能泄露。权限边界的核心是“最小授权”也就是某个工具在完成它正常功能的前提下能访问的路径、能执行的命令、能读取的变量都应该被压到最小而不是简单区分能读或能写。5.4 每周一次配置复查成本很低但很值最后分享一个我自己坚持的小习惯每周抽五分钟做一次 MCP 配置复查。命令其实很简单用find ~/.config -name *.json -o -name *.toml -mtime -7找最近一周改过的配置文件逐一眼看有没有出现新的 MCP Server再用ps aux | grep -i mcp看有没有异常进程在后台跑最后用lsof -iTCP -sTCP:LISTEN检查本机开放了哪些端口凡是 MCP 相关但没有绑定回环地址的都要问一句为什么。这套检查不能防住所有高级攻击但能帮你及时发现“某天为了调试顺手改了权限”“某个配置被同步工具带出去了”这类低级问题。老实说大部分 MCP 安全事故都不是黑客多牛而是自己的配置在某个深夜被随手改松了复查就是为了把这种坑提前填掉。写到这差不多了最后再补一段实际体会。我自己最严重的一次翻车是在公司共享开发机上给.env设了个 644 权限当时觉得“反正这台机器就几个人”结果第二天同事跑测试脚本时顺手cat了一下那个目录直接看到了云平台密钥后面我只能用重新生成密钥、改权限、加日志审计三件事来收尾。那次之后我才真正把“MCP 安全”当成一个持续过程而不是一次性配置。如果你现在刚配完一个 MCP建议别急着高兴先把这篇文章里的四道检查都跑一遍尤其是 Secret 和权限边界这两块改好之后你会明显踏实很多。
