这两天我一直在看 MCP 那个安全争议。

一开始它看起来像技术圈的事。

又是 SDK。

又是 STDIO。

又是 RCE。

又是供应链。

很多做增长、内容、官网和产品的人，可能看到这里就划走了。

但我觉得这件事和他们非常有关。

因为它刺到的不是一个协议。

是很多团队现在最兴奋的一件事。

把 AI 接进真实工具里。

你想想看。

过去我们用 AI，大多数时候是在一个聊天框里问问题。

它答错了，最多是文字错。

你可以删掉。

你可以重问。

你可以当它没发生过。

可一旦你开始给它接工具，事情就变了。

它能读文件。

它能看数据库。

它能改配置。

它能跑脚本。

它能操作浏览器。

它能把一段原本只在脑子里的建议，变成系统里真的发生的一次动作。

这才是今天真正该警惕的地方。

不是 AI 会不会更聪明。

而是它开始有手了。

说真的，我觉得很多团队会在这里犯一个特别自然的错。

他们会先问能不能接。

能不能接 Notion。

能不能接 GitHub。

能不能接飞书。

能不能接 CRM。

能不能接数据库。

能不能接浏览器。

这个问题当然重要。

但它不是第一个问题。

第一个问题应该是，接上以后它到底能碰什么。

能读，还是能写。

能看全量，还是只能看一小块。

能自己执行，还是必须让人确认。

能长期保存权限，还是每次只给一段临时权限。

出事的时候，谁能马上停掉。

这些问题如果没想清楚，接得越快，风险越大。

我跟你说，MCP 这次争议最有提醒价值的地方就在这里。

The Hacker News 报道里提到，OX Security 把问题归到一种架构层面的弱点。

他们说这个问题影响了大量公开可访问服务器和累计上亿下载的软件包。

OX 自己的技术文章里，真正吓人的也不是某一个产品写错了一行代码。

而是一类配置可以走到命令执行。

它本来是为了让系统启动一个本地工具服务。

可一旦这层配置被不该信任的人或内容碰到，就可能变成直接执行命令的入口。

这事儿听起来很技术。

但落到业务里，其实很朴素。

你把一个会听指令的东西，接到了一个能动手的地方。

那你就不能只问它聪不聪明。

你得先问它有没有边界。

我有时候觉得，今天很多 AI 接入项目最大的问题，不是太慢。

是太顺。

演示太顺了。

一句话拉数据。

一句话改文档。

一句话生成报告。

一句话更新状态。

一句话替你跑完一段流程。

看起来特别爽。

可很多危险就是藏在这个爽感里。

因为演示的时候，大家最容易看结果。

不会看权限。

不会看日志。

不会看失败以后谁接手。

不会看它有没有碰到不该碰的资料。

不会看它有没有把一个临时权限变成长期入口。

更不会看某个外部页面、某段复制来的提示、某个第三方 server，能不能影响它下一步做什么。

等到它真的进了工作流，问题才会冒出来。

它为什么能看这份客户名单。

它为什么能写这个配置。

它为什么能访问生产数据。

它为什么能把一个测试动作推到正式环境。

它为什么出错以后没有人知道。

这些问题听着像安全团队的事。

但坦率的讲，它们也是增长团队、内容团队和创始人的事。

因为你把 AI 接进工作，不是为了多一个玩具。

你是想让它真的影响业务。

只要它影响业务，它就一定会碰到权限。

会碰到客户信息。

会碰到价格。

会碰到合同。

会碰到后台。

会碰到内容发布。

会碰到线索分配。

会碰到钱。

所以这件事不能等到技术同事最后兜底。

它应该在接入前就被拿出来讲。

我会把问题拆得更土一点。

先别问你们要不要上 MCP。

也先别问你们用哪个 agent 平台。

先打开一张表。

把你准备接给 AI 的东西写下来。

文件。

数据库。

代码仓库。

日历。

邮箱。

CRM。

内容后台。

支付后台。

云服务。

每一个后面都写三件事。

它能不能读。

它能不能写。

它能不能执行。

只要第三项是能执行，就不要把它当普通集成看。

那已经不是内容助手。

那是一个能改变系统状态的人。

只是这个人没有人的常识，也没有人的责任感。

它只会按上下文往前走。

所以你要把边界先写在系统里。

不是写在团队群里。

不是靠大家记得小心一点。

也不是靠一句这个功能先别乱用。

真要接进工作流，至少要有四个底线。

第一，默认只读。

能不写，就别写。

能只看一小块，就别给全量。

尤其是客户数据、价格、合同、生产配置和账号权限，别一上来就全开。

第二，执行动作要隔离。

能在测试环境跑，就不要直接碰正式环境。

能用临时 token，就不要长期授权。

能在沙箱里处理，就不要让它直接贴着生产系统跑。

第三，关键动作要人确认。

不是每一次都打断。

但会影响客户、账单、发布、权限、删除、外发的动作，必须有人点一下。

AI 可以准备。

人来批准。

第四，所有调用要留痕。

谁让它做的。

它看了什么。

它调用了哪个工具。

它改了什么。

它失败在哪里。

这些不是为了写报告。

是为了出问题的时候，团队能追得回来。

没有留痕的自动化，短期看很轻。

长期看很贵。

因为一旦坏了，你连它怎么坏的都不知道。

这也是我今天不想把这篇写成安全新闻的原因。

安全新闻会让人觉得那是别人的专业领域。

但 AI 接入边界不是别人的事。

只要你让 AI 开始动你的工具，它就是你的事。

做内容的人会遇到这个问题。

AI 能不能直接发公众号。

能不能直接改官网。

能不能直接同步 LinkedIn。

能不能直接读用户评论和私信。

做增长的人也会遇到这个问题。

AI 能不能改投放预算。

能不能导出线索。

能不能给客户打标签。

能不能自动跟进。

做产品的人更会遇到。

AI 能不能查数据库。

能不能跑迁移。

能不能改配置。

能不能替用户完成一个关键动作。

这些都不是简单的是或否。

真正好的接入，不是把所有门都打开。

而是把每一扇门开到刚好够用。

不是说大家就不要用 agent。

相反，我觉得真正要用的人，更应该早一点补这层。

因为 agent 越有用，越会靠近真实工具。

越靠近真实工具，越不能只靠口头边界。

你不能一边期待它替你做事，一边又不告诉它哪里不能碰。

也不能一边把它接进后台，一边假装它只是一个聊天框。

回到今天这个 MCP 争议。

它真正给普通团队的提醒不是，某个协议完蛋了。

也不是所有 agent 都不能用。

它更像是在提醒我们，AI 进入工作流以后，连接能力本身会变成风险放大器。

你接得越多，系统越需要边界。

你让它越能动，越要能停。

你让它越接近客户和生产环境，越要知道它刚才到底做了什么。

这话听着有点刺耳但，很多团队现在不是 AI 接得不够快。

是接得太像试用。

试用时大家看爽不爽。

生产时你要看出事后能不能收回来。

这两个标准完全不一样。

所以今天最该做的动作很简单。

不要先开第十个连接器。

先盘一遍前九个。

它能读什么。

它能写什么。

它能执行什么。

它有没有沙箱。

它有没有审批。

它有没有日志。

它有没有停用开关。

如果这些都回答不上来，那你缺的不是更强的 agent。

你缺的是一条能让 agent 安全进业务的边界线。

没有这条线，效率越高，心里越虚。

有了这条线，AI 才真的有机会从演示，走进你的工作。

参考信号

• • The Hacker News，Anthropic MCP Design Vulnerability Enables RCE，2026-04-20
• • OX Security，The Mother of All AI Supply Chains Technical Deep Dive，2026-04-15
• • ITPro，AI agents using Anthropic MCP could be a vector for supply chain attacks，2026-04-15
• • TechRadar，Experts flag security issues at the heart of Anthropic MCP，2026-04-16
• • Reddit，r/webdev、r/ClaudeAI、r/theprimeagen、r/aigossips 近一周围绕 MCP 风险与 agent 权限边界的讨论