夜雨聆风上一篇讲 MCP，我尽量把它说成一个「统一插头」。但只讲插头还不够。因为只要人工智能开始接文件、数据库、网页、代码仓库和命令工具，真正要紧的问题就变了。
正文首图使用完整横图，不裁切。封面缩略图单独上传给公众号接口。
不是「能不能接」，而是「该不该接」。不是「能不能自动化」，而是「给了多大权限，出了事谁能拉回来」。
这篇不写成安全恐吓。普通人也没必要一上来学一堆专业术语。我们先拿 MCP 这种正在变热的工具连接方式举例，整理一张更实用的检查清单。以后你看到任何让人工智能连接工具的项目，都可以先照这七个问题过一遍。
MCP 官方文档说明，它是一套让应用为大模型提供上下文的开放协议。
一、它到底要接什么
第一个问题最朴素。这个工具到底准备让人工智能接什么？
如果只是接一份公开网页，风险很低。如果接的是本地资料库、客户表格、代码仓库、数据库、命令行，那就完全不是一回事。工具对象越靠近你的真实资产，越不能只看教程写得多顺。
比如文件系统服务这种东西，它的价值很明显，人工智能终于能读文件、写文件、移动文件、搜索文件。可它的风险也同样明显，因为文件系统不是玩具，它可能直接碰到你的项目、合同、密钥、客户资料和历史档案。
文件系统类 MCP 服务的功能包括读写文件、创建目录、移动文件、搜索文件等，因此权限范围必须先看清。
二、它是只读，还是可写
第二个问题更关键。它只是让人工智能看一眼，还是允许人工智能动手改？
只读和可写是两个世界。只读权限最多暴露信息，可写权限会改变现场。能写文件、改配置、提交代码、更新数据库、调用外部接口，这些动作一旦出了问题，就不是「回答错了」那么简单。
只读权限像隔着玻璃看文件，可写权限像拿起印章修改现场，风险级别完全不同。
所以我建议普通用户先养成一个习惯，看到任何工具接入，先问它有没有只读模式。如果没有，再问能不能人为限制写入范围。如果连这个都说不清，那就别急着接到真实流程里。
三、权限范围有没有被圈住
第三个问题是范围。不是说你给了文件权限，就应该让它看到整个电脑；不是说你接了数据库，就应该让它查所有表；不是说你接了命令工具，就应该让它执行所有命令。
最小权限不是安全行业的漂亮话，而是自动化能不能长期使用的底线。你让人工智能处理某个项目，就只给它这个项目目录。你让它分析一张数据表，就只给它那张表或只读视图。你让它调用一个工具，就限定它能调用的工具和参数。
能进工作流，不等于能进所有房间。先把允许范围圈出来。
这个原则对小团队尤其重要。很多小团队没有专门安全人员，靠的就是流程设计本身别太冒险。权限范围一旦给大，后面再指望人工智能每次都自己守规矩，就有点天真了。
四、外部内容有没有隔离
第四个问题经常被忽略。人工智能接工具之后，可能会处理大量外部内容，网页、邮件、文档、评论、用户上传文件、第三方教程。外部内容里不一定只有正文信息，也可能藏着试图影响智能体行为的指令。
这就是为什么很多 MCP 安全资料都会提到提示词注入、工具投毒、权限滥用这些风险。你不用被这些词吓到，先理解一个简单事实，外部内容不能直接当成系统指令。它可以是资料，但不应该越过边界去命令你的智能体。
网页、邮件、文档这类外部内容应该先过检查门，不要直接进入工具执行链路。
如果一个流程会读取陌生网页或用户上传文件，就应该有隔离层，有检查，有人工确认。至少要把「读取资料」和「执行动作」分开，不要让一段外部文字直接推动写入、删除、转账、发布这些动作。
五、来源靠不靠谱
第五个问题是来源。开源项目不等于自动可信，星标多也不等于适合你。更别说有些教程只是别人跑通了一个演示，不代表能放到你的生产流程里。
看一个工具，至少先看四件事，官方文档是否清楚，仓库是否还在维护，权限说明是否透明，社区反馈是否能看到真实问题。只要其中一项很模糊，就别把它直接接进核心资料和业务动作里。
文档、维护、权限、反馈，是判断一个工具能不能接进真实流程的四个入口。
这里还有一个很现实的点，很多工具安装命令看起来很方便，复制一行就能跑。但越是这种「一行命令直接安装」的东西，越要知道它从哪里来、会装什么包、会读取哪些环境变量。
六、有没有扫描和审计
第六个问题，是有没有办法检查。
现在已经出现了一些专门面向智能体、MCP 服务和工具权限的安全扫描项目，比如 AgentShield 这类工具，它会关注智能体配置、MCP 服务、工具权限、硬编码密钥、提示词注入面、钩子风险等问题。我们不需要把任何一个工具神化，但它说明一件事，智能体安全已经不只是概念讨论，开始出现具体检查工具了。
AgentShield 这类项目把智能体配置、MCP 服务和工具权限纳入扫描范围，说明权限检查正在工具化。
普通用户不一定马上要上扫描工具，但至少要有审计意识。谁接入了什么工具，给了什么权限，最近有没有改过配置，运行时有没有日志，这些东西要能查到。没有记录的自动化，出了事就只能靠回忆。
七、出问题能不能回滚
最后一个问题，是回滚。
很多人做自动化时只关心它能不能跑起来，很少问它跑错了怎么办。可一旦工具有写入能力，回滚就不是高级功能，而是基本保险。
MCP 相关安全项目已经在跟踪实现、工具和基础设施中的漏洞类别。
你要知道它改了哪些文件，调用了哪些接口，写了哪些数据，发布了哪些内容。最好能有日志、版本、备份、撤销按钮，或者至少让关键动作先经过人工确认。
自动化不是一脚油门踩到底，而是知道哪里能刹车、哪里能回退。
这张表，可以先抄走
以后看到任何「给人工智能接工具」的教程，我建议先用这张表扫一遍。不是为了显得谨慎，而是为了让自动化真的能长期用。
| 问题 | 你要确认什么 | 风险信号 |
|---|---|---|
| 接什么 | 文件、数据库、网页、代码仓库、命令行、业务系统 | 越靠近真实资产越要谨慎 |
| 能做什么 | 只读、写入、删除、执行命令、外部调用 | 可写和可执行是高风险 |
| 权限范围 | 目录、表、账号、接口、工具是否被限定 | 范围说不清就先别接 |
| 外部内容 | 网页、邮件、文档是否和执行动作隔离 | 外部文字能直接触发动作 |
| 来源依据 | 官方文档、仓库维护、权限说明、社区反馈 | 只有二手教程，没有维护记录 |
| 审计记录 | 配置、权限、运行日志、扫描报告 | 出了问题查不到谁做了什么 |
| 回滚兜底 | 备份、版本、撤销、人工确认 | 能改不能撤，能发不能停 |
如果这七项里有三项说不清，就不要把它接到核心流程里。可以先在测试目录、测试数据、只读账号里跑一遍。跑通以后，再一点点扩大权限。
这不是保守。恰恰相反，这是让人工智能真正进入工作流的前提。因为只有边界清楚，自动化才敢变深。
资料来源
本文为公开资料整理，不伪装成实测教程。主要依据包括 Model Context Protocol 官方文档、官方文件系统服务仓库、AgentShield 开源项目、Model Context Protocol Security 已知漏洞页面，以及相关 MCP 安全资料。
参考链接：modelcontextprotocol.io/introduction；github.com/modelcontextprotocol/servers/tree/main/src/filesystem；github.com/affaan-m/agentshield；modelcontextprotocol-security.io/known-vulnerabilities。
上船，让我们去人工智能世界冒险吧。
