过去数周间，模型上下文协议（Model Context Protocol，MCP）快速崛起为第三方数据与工具接入LLM对话系统的实际标准。互联网短时间已充斥着各类炫酷应用案例，想象空间极为广阔。但这个协议背后却也暗藏一些微妙的安全隐患与功能的局限性。
背景
MCP的本质是构建"智能助手插件生态"的桥梁，让用户能为各种支持了MCP协议的大模型和AI客户端提供本地扩展能力，让这些基于LLM的智能界面可以通过MCP的"工具调用"执行非文本操作，MCP协议实际上是标准化了LLM和本地数据、工具的对接方式。
比如在前文【】中，我们只是在 Cursor 中告诉大模型: “访问www.saucedemo.com网站，使用problem_user登录，验证该网站完整流程并记录发现的问题” , Cursor 就会通过playwright-mcp 这个 mcp server来调用playwright框架完成浏览器的调用、访问、浏览、测试、记录问题等一系列活动，完成跟手工测试工程师类似的测试活动
所以通过MCP，它的核心价值就是突破了原来AI大模型文字型咨询助手的角色，转变为实际的执行者角色，更能够直接操作本地的工具和数据，为大模型提供了万能插口。
潜在的隐忧
但我们在看到MCP巨大潜力的同时，也要看到，MCP作为刚起步不久的一个基础协议，尚不能称为尽善尽美，要看到还有如下一些隐忧：
隐患一：协议本身的安全性
认证机制
MCP的初始版本未定义认证规范，导致各MCP服务器可自行其是，从繁琐的验证到敏感数据裸奔，可谓乱象丛生。虽后续推出认证方案，但实现复杂度引发新的争议。
恶意代码本地执行风险
协议支持通过标准输入输出运行MCP服务器，这样虽然降低使用门槛，却也为恶意代码传播提供了温床。如果技术小白执行第三方恶意MCP代码引发本地设备安全故障，已成新型攻击手段。
MCP对用户输入的信任
很多Mcp Server会直接执行用户的输入指令。当用户意图经LLM转译并对系统产生作用时，传统安全模型面临严峻挑战：用户输入指令与攻击系统的边界不再清晰。
隐患二：交互设计上的限制
MCP协议更多是面向LLM交互，但针对用户来说，交互方式谈不上易用、友好。
缺少针对不同等级的操作风险分级
很多助手工具会提供全局的操作确认机制，但针对很多无害工具养成的“自动确认”习惯，往往会导致一些严重误操作的发生，比如本地重要文件的删除、邮件误发等情况。
成本控制能力
与传统协议不同，LLM场景下依据不同token的返回量会产生数额不等的费用，而用户服务成本高度依赖MCP工具的词元效率，而目前协议中并没有对返回长度的限制以强化成本控制。
牺牲结构化数据的优势
为适配LLM偏好，MCP偏向采用类似人类可读的方式，如纯文本/图片/音频片段传输，而牺牲结构化数据优势。比如类似像地图、滴滴叫车等服务，需确保位置准确性、行程细节反馈、实时状态更新等需求的话，现有协议难堪重任。目前解决这类问题还需要在工具层做一些变通的额外设计
隐患三：LLM的安全性
大模型本身安全性的探讨，目前还悬而未决，而引入MCP连接更多的数据、工具让这个问题更为凸显。
MCP让提示词注入能力更强悍
LLM 通常有两层指令：系统级提示词（控制助手的行为和策略）和用户级提示词（由用户提供）。通常，以前提到提示词注入通常指恶意的用户输入。而MCP 模型一个相当大的漏洞是允许第三方提供的工具被信任为助手系统级提示的一部分，从而赋予它们更大权限来覆盖代理行为。
敏感数据泄露
除了恶意地通过恶意工具劫持外，MCP也可能让用户在无意中泄露敏感数据。即便用户严格确认每个操作，数据仍可能通过"合理"的方式外泄出去。比如你的指令：“帮我解释一下个人病历记录”，助手可能会启动一个医疗检索类的多租户MCP工具，并把个人隐私信息泄露到服务提供商。
包括MCP Server也很容易通过伪装提示词和实际的工具实现，劫持、更改用户的意图。
隐患四：打破企业中的传统数据权限控制
与直接泄露敏感数据不同，企业在将大量内部数据通过MCP连接到LLM以后，可能会让普通员工访问或推断出无权访问到的数据。
举例来说，如果一个企业的所有内部文档都接入LLM，员工通过助手：
“根据所有我有权限访问的文档和公司的任免通知，推断尚未宣布的重大事件如裁员行动”
或者一个经理级别的人：
“我看到内部wiki上有一条匿名的针对XXX的负面评价，内容是XXXX，请分析XX团队中成员的发言记录并推断最可能是谁写的这条评价”
隐患五：LLM自身的能力局限
对于大规模的MCP集成，LLM本身的负载能力很可能无法承受。Google推出的A2A协议(Agent to Agent) 可能是解决手段，另当别论。
MCP的能力发挥依赖于被助手集成的LLM
一个事实是并非工具越多，数据越多，结果越准确，恰恰相反，同类的数据和工具越多，会导致最终输出的精确性越差。随着MCP Server的数量越来越多，集成的工具越来越多，AI助手的性能也将显著下降，并且请求和分析的成本也会增加。
工具实现和用户预期的落差
很多MCP Server在实现上其实是编写调用本地已有工具的函数方法，MCP Server的能力其实主要受这些函数方法的制约。如果用户对具体的函数实现没什么了解，只是按通常的人为沟通思路和LLM交互，很可能难以获得满意的结果。
“请为我查找最近所有博客中包含AI测试相关的文章”，这个指令其实需要本地MCP Server具备全文检索本地文本内容的能力，但如果集成的MCP Server仅仅包含了文件查找的功能，自然得不到相应的结果。
结论和展望
MCP的诞生顺应了AI时代的数据整合需求，其日常应用价值毋庸置疑。但我们也需要清醒认知：MCP协议还在成长期，我们在拥抱应用的同时，也需要认识到其中的风险， 将LLM与数据的结合，会放大既有风险，也催生了新型的威胁。
本文大部分观点参考了Shrivu的博客内容