Model Context Protocol 正在成为 AI Agent 连接工具、文件、API、开发环境和内部系统的默认方式之一。这很有用，但也改变了安全模型。工具描述不再只是文档，工具参数不再只是表单字段，本地 server 也不再只是开发者便利工具。在 Agent 工作流里，这些内容都可能影响模型下一步做什么。
这份清单面向希望使用 MCP、但不想默认信任所有 server、工具描述和工具输出的团队。它更适合产品构建者、安全评审人员、工程负责人和创业者，用来做上线前检查，而不是做抽象的协议讨论。
1. 盘点所有 MCP server
先做一张简单清单：允许哪些 MCP server？每个 server 谁负责？运行在哪里？哪些 Agent 或 client 可以连接？暴露了哪些工具？读取哪些数据源？能修改哪些系统？如果这些问题答不上来，就还不适合把集成当成生产就绪。
清单应该包括本地开发 server、托管供应商 server、内部实验 server，以及通过模板或 marketplace 安装的 server。影子 MCP server 尤其危险，因为它们可能悄悄增加工具能力，而安全和产品团队从未评审过。
2. 把工具描述当成攻击面评审
MCP tool poisoning 的危险在于，恶意指令可以藏在工具元数据里。模型可能看到一段用户从未读过的工具描述。如果这段描述要求模型忽略之前的指令、隐藏参数、调用另一个工具或泄露上下文，普通界面里很难发现问题。
团队应该评审工具名称、描述、schema、示例、参数标签和错误信息。把它们当作能够通过模型“社会化执行”的代码注释。描述应该短、事实化，并且不包含工具契约之外的行为指令。
3. 要求 descriptor 完整性
工具在评审时可能安全，但后来 descriptor 改了就不安全了。这就是 MCP 风险里的 rug pull。一个 server 可能保留相同工具名，却修改描述、参数 schema、endpoint 行为或下游目标。
最低要求是在批准时记录 descriptor hash，并在变化时报警。更成熟的做法可以使用签名 manifest、固定版本、部署审批和自动 diff review。关键点是：工具 descriptor 在获得信任后不能静默漂移。
4. 区分只读工具和写入工具
只读工具和可写工具需要不同处理。搜索文档、列出项目或读取工单，和发送邮件、编辑文件、创建 pull request、修改客户记录、退款或运行命令不是同一类风险。
给每个工具设置风险等级。低风险只读工具可以默认可用；高风险写入工具应该要求策略检查、用户审批或独立服务账号。除非有充分理由和强监控，不要把广泛读取权限和广泛外部通信能力组合在同一个 Agent 里。
5. 审批前必须显示参数
如果用户看不到 Agent 将要发送的真实参数，审批就很弱。一句“允许工具调用”不够。审批界面应该显示工具名、目标、记录 ID、文件路径、命令文本、外部 URL、payload 摘要，以及动作是否可回滚。
这很重要，因为很多 MCP 风险依赖隐藏或混淆参数。如果 Agent 要上传文件，用户应该看到路径；如果要调用 CRM 工具，用户应该看到客户记录；如果要执行 shell 命令，完整命令应该可见且可复制。
6. 不要把工具输出当成指令
工具输出通常是不可信内容。搜索结果、文档、工单、仓库文件、网页或 API 响应，都可能包含针对 Agent 的指令。Agent 不应该把这些输出当成新的 system instruction 或 developer command。
好的实现会把工具输出标记为数据，保留来源身份，并阻止检索文本改变工具权限或任务目标。当 Agent 读取公开网页、第三方 issue tracker、共享文件夹、客户上传内容或外部知识库时，这一点尤其重要。
7. 限制本地机器访问
MCP 经常用于开发者工作流，Agent 可以查看文件、运行测试、安装依赖或执行命令。这很强，也很危险。恶意 README、markdown 排障说明、package script 或仓库 issue，都可能诱导乐于帮忙的 coding agent 执行不安全动作。
尽量让 coding agent 在沙箱中运行。限制文件路径，保护密钥，避免挂载 home 目录，对 shell 执行要求明确审批，并在分析不可信仓库时限制网络访问。在完成评审前，把陌生仓库当作敌对输入。
8. 控制外部通信
数据外泄通常需要目的地。如果 Agent 既能读取敏感数据，又能发送任意 HTTP 请求、邮件、聊天消息或文件上传，影响范围会迅速扩大。出站控制是降低 MCP 风险最实用的方法之一。
使用外部域名白名单，阻止未知 webhook，限制文件上传，并记录出站请求。对内部工具来说，服务账号不应该能把数据发送到它不需要的目的地。成本监控和异常网络模式也应该被视为安全信号。
9. MCP server 保持最小权限
MCP server 不应该因为方便就持有宽泛生产凭证。给它支持工作流所需的最小数据范围和动作范围。开发、预发、生产环境使用不同服务账号。定期轮换 key，并移除不再使用的工具。
最小权限同样适用于 Agent client。如果某个工作流只需要工单总结，就不应该继承数据库写入、终端命令、客户退款或源码修改工具。
10. 记录完整决策路径
一旦出问题，团队需要复原 Agent 的路径：哪个用户请求启动了运行？当时有哪些工具可用？模型看到了哪些工具描述？工具返回了什么输出？哪些工具调用被提出、批准、拒绝或执行？
日志应该记录 prompt、检索来源、工具元数据版本、参数、审批、输出、错误、重试、延迟和成本。不要明文记录密钥，但要保留足够证据用于事故响应和回归测试。
11. 测试真实攻击场景
不要只测 happy path。准备一个小型回归测试集，包含被污染的工具描述、恶意网页、敌对 markdown 文件、混淆参数名、相似工具、超大输出，以及把读取工具和外部通信工具组合起来的尝试。
测试要回答一个实际问题：Agent 是否能被诱导泄露私有数据、调用错误工具、向用户隐藏参数、执行命令，或把不可信内容当作指令？如果答案是能，就需要更多控制措施再上线。
12. 定义回滚方案
如果团队知道如何快速禁用工具，MCP 事故就更容易控制。上线计划应该包括 kill switch、server allowlist 变更、凭证轮换、缓存失效、日志导出、客户沟通负责人，以及恢复安全运行的路径。
不要等事故发生后才决定谁能撤销 MCP server。负责人、升级路径和回滚命令应该在上线前就明确。
实用上线规则
如果一个连接 MCP 的 AI Agent 能读取私有数据、调用工具、运行代码或对外通信，它就需要在生产前做安全评审。评审不一定慢，但必须明确：inventory、permissions、descriptor integrity、approval visibility、sandboxing、outbound controls、logs、tests 和 rollback。
参考资料
- OWASP Top 10 for Large Language Model Applications
- MCP threat modeling 和 tool poisoning 研究
- MCP 与 prompt injection 安全分析
- AI-assisted development tools 与 prompt injection 研究
- 2026 年 AI Agent 安全热词
如果要做更完整的上线评审，可以使用 AI Agent 就绪度自评，或参考 AI Agent 工具风险登记表模板。