工具描述，也可能成为攻击入口
面向2026年的AI应用开发，接入MCP服务时，开发者需要审查的不只是接口功能，还有模型会读到的工具元数据。MCP让应用通过标准化接口连接外部工具，而工具名称、描述和参数说明，也可能影响模型选择与调用工具。所谓工具投毒，典型方式是在这些内容中夹带恶意指令，诱导模型偏离用户任务，读取敏感信息或执行非预期操作。关键风险是外部说明被当成了行动指令，并不意味着所有MCP服务都存在恶意。([developer.microsoft.com](https://developer.microsoft.com/blog/protecting-against-indirect-injection-attacks-mcp/?utm_source=openai))
先问一句：这与任务有关吗？
识别投毒时，应优先检查工具说明是否越过职责边界，而不是只搜索“忽略指令”等关键词。例如，一个计算工具若要求先读取本地凭证、向外部地址发送内容，或声称这些步骤“不可向用户透露”，就应停止接入并核查。这些是用于审查的假设性信号，不是某款产品的既定行为；真正要判断的是，相关要求是否有完成任务的必要性与明确授权。还要留意跨工具指令：恶意描述可能引导模型调用其他可信服务，攻击者自己的工具甚至不必被执行。([invariantlabs.ai](https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks?_bhlid=e14f597bbf3f627387f835154c196c6e05fa28d6&utm_source=openai))
审查完整定义，持续追踪变化
接入前应查看完整工具描述、参数名称与结构，而不是只凭展示名称或“只读”标签判断安全性。将审核过的定义保存为基线，记录版本或摘要；定义发生变化时重新审查，可帮助发现先建立信任、再替换说明的攻击。但定义未变，不代表服务端行为未变，元数据校验不能替代代码审查和运行监测。自动扫描适合辅助筛查，敏感调用仍需展示实际参数，并在执行层落实授权。([cheatsheetseries.owasp.org](https://cheatsheetseries.owasp.org/cheatsheets/MCP_Security_Cheat_Sheet.html?utm_source=openai))
让权限边界承受识别失败
人工审查和模型判断都不能保证发现所有注入，因此防线必须延伸到模型之外。本地MCP服务应在受限环境运行，只开放任务必需的目录与网络目标，避免直接继承开发者主机上的全部访问能力。不同服务使用独立、最小权限凭证，按任务启用工具，并限制不必要的外部通信，可以缩小误调用的影响范围。尤其不要把“模型已被提醒不要泄密”当成访问控制，真正的限制应由沙箱、网络策略和后端权限执行。([owasp.github.io](https://owasp.github.io/DevSecOpsGuideline/2-Process/2-2-Develop/2-2-5-AI-Agent-and-MCP-Security/?utm_source=openai))
用调用记录，把审查变成闭环
上线后的观察重点，是工具调用是否仍与用户意图一致，尤其要关注无关文件访问、异常外发和非预期的连续调用。开发者应保留可追溯的调用记录，并让敏感操作的确认发生在模型无法自行绕过的执行流程中。对工具返回内容，可用固定结构与字段校验减少异常输入，但格式合法不等于语义安全，自由文本中的注入也不能仅靠结构校验排除。归根结底，识别工具投毒不是寻找一句万能拦截词，而是持续核对来源、任务、权限与实际行为是否一致。([community.owasp.org](https://community.owasp.org/attacks/MCP_Tool_Poisoning?trk=article-ssr-frontend-pulse_little-text-block&utm_source=openai))
