企业接入第三方 MCP 服务器之前，安全要先查哪几项

接入第三方 MCP 服务器，等于在企业内网安装了一个能被 AI 助手调用的可执行程序。保障 MCP 服务器安全，不能只看功能演示，要在接入前核验四项：运行账号的权限边界、参数里的路径与网址校验、认证与版本跟踪、出事后的凭证轮换预案。除了常见的工具入口，提示词与静态资源通道同样需要逐项排查。

真实案例：提示词入口引发的任意文件读取

Grafana 2026 年 10 月 5 日在官方安全公告中发布了 CVE-2026-89039 漏洞，评分 6.5（中危），影响其压测工具 MCP 服务器 mcp-k6 在 0.3.0 到 0.7.0 之前的版本。调用方在调用 convert_playwright_script 这一提示词时，传入一个普通文件路径，就能直接读取运行该服务账号可读的任意文件，包括家目录里的 SSH 密钥与云平台访问凭证；即使服务限制了带 @ 前缀的工作目录，攻击者也能通过工作目录里指向外部的符号链接绕过限制。该问题已在 0.7.0 修复。

MCP 协议除了开放工具（tools），还包含提示词模版（prompts）与上下文资源（resources）。只要代码没有把好输入关，任何一个读取本地文件的入口，都会变成攻击者窃取内网凭证的跳板。

第一步：运行账号与环境隔离

开发人员在本地调试时，习惯用个人开发账号直接启动第三方 MCP 服务器。这种做法风险很大：服务器进程继承了当前用户的完整文件读取权限，用户的 .ssh/id_rsa 私钥、云平台访问密钥以及本地浏览器缓存，全部暴露在该进程可读的范围内。一旦该组件存在类似上述的文件读取漏洞，攻击者拿到这些密钥，就可能登录其他机器或云账号。

规范的运行方式是配置独立的低权限服务账号。该账号不具备管理员权限，家目录保持清空，不存放任何系统登录凭证。在文件系统的共享与沙箱隔离方面，环境配置原则可参考 多个 Bot 共用云电脑，文件怎么隔离。把进程限制在专属运行目录中，即便代码出现读取漏洞，能读到的也只是这个空目录。

第二步：输入参数检查，字符串前缀挡不住符号链接

第三方 MCP 服务器通常会暴露接受文件路径、URL 网址或查询语句的参数。审查时要把每个接口翻开，看底层代码究竟如何判断参数的合法性。很多开源实现为了省事，只做简单的字符串前缀比对，比如检查路径开头是否属于项目目录。

单纯依靠字符串前缀做校验很容易被绕过。攻击者可以在受信任目录内创建一个指向系统敏感文件的符号链接，或者利用相对路径向上跳出目录。规范的代码实现需要在操作文件前，调用系统底层接口解析出真实的物理路径，确认目标文件确实落在允许访问的目录白名单内。

对于接受 URL 网址的参数，要检查代码是否支持限制访问目标。如果 MCP 服务器允许传入任意网络地址，它就可能被利用发起内网请求伪造，去探测公司内网的元数据服务或数据库端口。

第三步：认证与版本跟踪

如果 MCP 服务器以本地子进程方式启动，要确认父进程与子进程之间的标准输入输出受到系统访问控制；如果采用网络端口通信，则需要配置强身份令牌或双向传输加密，不能让局域网内任意机器无密码直连。

开源生态中的 MCP 服务器迭代非常频繁，安全漏洞往往伴随着版本升级被修复。企业引入第三方组件，要明确专人跟踪上游仓库的安全公告。当官方发布新版本时，及时在测试环境验证并平滑升级。升级时不能只替换文件，还要核对接口规范的变化，避免旧提示词或工具调用方式失效导致业务中断。

在正式接入核心业务系统前，使用合成数据对工具接口进行边界与容错测试，具体思路可参考 Agent 接 CRM 之前，上线测试先跑模拟企业数据？。

第四步：异常响应预案与准入清单

企业应当在接入登记表中明确记录：该 MCP 服务器运行在哪些机器上、使用什么系统账号、能够接触到哪些业务系统的访问令牌。一旦上游爆出高危漏洞或者日志中出现异常探测行为，运维团队能马上动手：

首先，立即停止该 MCP 进程，并在 Agent 编排端摘除对应的工具与提示词入口，阻断外部调用；

其次，按照安全公告将组件升级至已修复的版本，核对官方发布的补丁逻辑；

最后，轮换该运行账号以及相关业务系统曾暴露出的全部密钥与访问令牌。不能仅仅重启服务，要假设在漏洞暴露期间，潜在攻击者已经读取过凭证并留存。

把这四项做成标准清单，业务部门提交接入申请时逐一过筛。

MCP 服务器安全：常见问题

MCP 协议本身有规范，为什么还需要企业逐项核验具体服务器？

协议只规定了消息交互的标准格式，不负责保障第三方代码的具体实现质量。MCP 协议定义了工具、提示词与资源的通信信令，但服务器具体如何读取文件、如何校验参数以及如何管理进程权限，取决于作者的代码怎么写。如果编写者缺乏安全意识，写出存在路径穿越或未授权访问的逻辑，协议本身无法提供防御，企业必须从操作系统与代码层面做核验。

只给 MCP 服务器开放只读权限，就不用担心安全风险了吗？

只读权限同样存在严重的数据泄露风险。很多安全事故是敏感信息被读走，跟写入或破坏数据无关。例如服务器运行账号可读本地 SSH 密钥、云平台令牌或内网数据库备份，攻击者利用只读漏洞把这些凭据提取出去后，就能在外部发起更大规模的渗透。不能因为功能是只读就放松警惕，限制可读范围与剥离敏感凭证同样关键。

团队缺少专职安全人员，如何落地第三方 MCP 服务器的接入审查？

缺少专职安全人员时，团队可以用轻量清单来落地接入审查。接入审查的重点落在三项动作上：第一，运行身份与开发环境解耦，给每个 MCP 服务器分配独立低权限系统账号，清理家目录里的私钥与配置；第二，收窄目录与网络权限，用操作系统自带的容器或目录权限做限制，只开放运行所需要的文件夹；第三，在接入审查表上记下责任人与上游项目地址，订阅版本更新通知，遇漏洞及时更新重启。