MCP最危险的不是漏洞，而是你把工具当插件装

我最近越来越不喜欢一句话：

“装个MCP就行。”

这句话听起来很工程师，很轻巧，好像AI接工具就是装插件、配JSON、跑起来。可真正放到企业和团队里，MCP最危险的地方恰恰不是某一个漏洞，而是大家把“工具接入”当成了“插件安装”。

插件坏了，大不了卸载。

工具接入坏了，Agent可能拿着你的身份去读仓库、查数据库、改工单、发请求、调用内部系统。

这两个东西不是一个风险等级。

MCP把工具接进来了，也把责任接进来了

MCP的价值很明确：它让AI Agent不用为每个外部系统单独写一套适配器。文件、数据库、API、SaaS、代码仓库、企业系统，都可以用相对统一的方式暴露给模型。

这当然是大好事。

但标准一旦流行，就会带来一个副作用：接入门槛越低，乱接的速度越快。

以前一个系统要接内部工具，至少还会经过接口评审、权限申请、上线流程。现在很多团队的真实状态是：开发者看到一个MCP server，复制一段配置，放进本地IDE或者Agent客户端，马上就能跑。

问题是，Agent不是普通客户端。

普通客户端大多按确定逻辑调用接口；Agent会根据上下文自己决定什么时候调用、调用哪个、怎么把多个工具串起来。它一旦拿到权限，实际行为就不再是“用户点了一下按钮”那么简单，而是一个非人身份在替你连续操作。

这也是为什么最近安全圈不断把MCP和“非人身份”“工具投毒”“供应链风险”“审计缺失”放在一起讨论。

你以为给的是工具，其实给的是钥匙串

我见过一些团队接AI工具时，最常犯的错误是把权限理解得太粗。

比如：

“给它GitHub权限，方便读代码。”

听起来合理。但具体给什么权限？只读还是写？只读一个仓库还是整个组织？能不能读issue？能不能看secret扫描结果？能不能触发CI？能不能改PR？

再比如：

“给它Jira权限，方便生成任务。”

那它能不能改状态？能不能改负责人？能不能读所有项目？能不能看到客户工单？

再比如：

“给它数据库查询权限，方便分析数据。”

那它能不能查生产库？能不能看到用户手机号？能不能导出结果？能不能把结果再交给另一个工具？

真正的问题不是MCP本身“坏”，而是MCP把这些问题暴露得更快了。

过去权限设计不清楚，最多是人乱用系统；现在权限设计不清楚，是Agent替人把所有系统串起来乱用。

我现在给团队的建议：先办工牌，再发工具

如果一个团队要认真用MCP，我不会先问“接了多少工具”。

我会先问五个问题。

第一，这个Agent有没有独立身份？

不要让它长期复用某个员工的个人token。员工离职、换岗、权限变化，Agent还拿着旧钥匙跑，这是迟早出事。

第二，工具权限是不是最小化？

能读就不要写，能限定项目就不要全组织，能走临时授权就不要永久密钥。Agent需要的是完成任务的最小能力，不是“为了方便先全给”。

第三，每次调用有没有审计？

我不只要知道“谁让Agent做的”，还要知道“Agent调用了哪个工具、传了什么参数、拿到了什么结果、下一步为什么这么做”。没有审计，出事以后只能靠猜。

第四，敏感动作有没有人工确认？

删除、发布、付款、改权限、导出数据、写生产系统，这些都不应该因为一句自然语言指令就自动完成。

第五，第三方MCP server有没有隔离？

不要把一个网上找来的server直接放进核心环境。能容器化就容器化，能网络隔离就隔离，能只给假数据测试就别上真数据。

这些听起来不酷，但这才是MCP从玩具走向生产的门槛。

MCP不会死，但裸奔式接入会死

我不认为MCP的安全争议会让它停下来。

恰恰相反，越多企业要用Agent，越需要一种标准化的工具连接层。没有标准，大家会写出更多私有、粗糙、不可审计的工具接入方式，风险只会更散。

但MCP要进入生产，不能靠“相信开发者小心一点”。

它需要像企业API一样被治理：身份、权限、网关、日志、审批、隔离、密钥轮换、风险分级，一个都不能少。

以后判断一个团队Agent用得成不成熟，我甚至不看它接了多少工具，而看它敢不敢回答：

这个Agent是谁？

它能做什么？

它不能做什么？

它做错了谁负责？

它每一步有没有记录？

如果这些问题答不上来，MCP接得越多，风险越大。

所以我的结论很直接：MCP不是别装，而是别裸装。

给Agent接工具之前，先给它办一张“工牌”。没有身份、没有权限边界、没有审计记录的Agent，不该碰你的真实系统。

你们团队现在接MCP了吗？最想接的是代码仓库、数据库，还是内部业务系统？我更想知道：你们有没有先把权限边界画清楚。