MCP无状态化引争议，开发者追问API本质回归

近日，Model Context Protocol（MCP）协议的无状态化设计成为开发者社区热议的焦点。一项调查显示，超过21,000个面向互联网的MCP服务器实例处于暴露状态，其中近92%的生产服务器未启用基础OAuth认证。这一数据与不断增长的CVE漏洞目录和OWASP MCP Top 10正式化进程同步显现，使得原定于2026年8月举行的MCP Dev Summit从一次例行行业交流演变为高风险的技术对峙现场。

MCP协议旨在标准化AI模型与本地及远程数据交互方式，但其快速普及正与一系列高关注度的安全披露正面碰撞。冲突的核心在于对协议架构的根本性分歧，特别是STDIO传输模型的安全性。OX Security于2026年4月发布的"AI供应链之母"报告指出，1.5亿个下游软件包下载可能受到影响，超过7,000台可公开访问的MCP服务器以及高达200,000个易受攻击的实例被识别。尽管这些发现令人担忧，Anthropic仍坚持STDIO行为属于"按设计"范畴，声称其执行模型是"安全的默认选项"，并将输入清洗的责任归于开发者一方。

安全社区则用不断积累的证据回击这一立场。2026年7月发表于arXiv的研究《Exposed by Design》检测到超过21,000个面向互联网的MCP服务器实例。在接受审计的640台生产服务器中，91.8%缺乏OAuth认证，687个实例被发现具有不受限制的shell工具访问权限。这些数据与不断增长的漏洞清单——包括逾10个严重或高危级CVE——相互叠加，使得首尔峰会上的这场对话不再是纸上谈兵，而是对一项正被全球开发者广泛采纳的技术底座展开的紧急排查。

与此同时，AI Agent在数据库操作中的权限控制难题也凸显了MCP工具设计的边界问题。一个典型的案例是订单取消流程：如果直接赋予Agent "execute_sql"权限，虽然技术上可行，但存在SQL注入、越权和误删数据等多重风险。为此，业界提出两阶段的订单取消流程：首先由Agent调用"prepare_order_cancel"检查订单状态并创建短期操作意图，然后用户确认后调用"confirm_order_cancel"提交取消申请。这种设计思路强调服务端校验输入、实施访问控制，并保留工具调用日志，以避免合法地做错事。

MCP官方Tools安全建议也明确要求服务端校验输入、实施访问控制、限制调用频率并清理输出；对敏感操作，客户端应向用户展示调用参数并请求确认，同时保留工具调用日志。然而，这种复杂的权限控制机制是否能有效应对日益严峻的安全挑战，仍有待实践检验。