众所周知,我最近在研究MCP,从原理到技术实现都研究了,还用Rust实现一些工具,但当对其内部运作方式了解后就会存在安全顾虑。MCP虽然确实非常方便,但安全与便利的权衡令人纠结!这些MCP服务是黑盒,需要仔细阅读代码才能放心使用。
作为一项新兴技术,MCP(Model Control Protocol)在带来便利的同时也引发了诸多安全顾虑。本文将系统分析MCP当前面临的安全问题,并以iterm-mcp为例探讨特性与风险,最后展望这一技术的未来发展趋势。
一、MCP的安全问题
一项技术的发展总是带来新的安全问题,远一点如上个世纪的汽车,近一点如GPT刚出来的时候,这里想举例说明一下,目前AI-Agent 带来比GPT更多的安全问题,有技术问题、隐私安全、有数据安全等各种问题,但终将解决。
从技术上看,目前很多MCP服务都是使用Nodejs 或者Python写的,客户端在启用这些服务的时候会以本地命令执行的方式运行,这可能造成极大的风险,谁知道这个mcp服务里面包含什么指令,会不会删除你的文件、上传你的数据。
从实践角度看,因为大部分都是普通用户,不具备专业鉴别能力,数据安全问题尤为突出,这需要完善的权限管理(包括读、写、执行分级)和智能过滤规则,这将是保障数据安全的关键。
以iterm-mcp为例简单分析
这里举个比较极端的例子,就是直接控制终端指令运行,事实上没有终端也可以运行指令对本地电脑进行操作,这个工具更直观一些。
iterm-mcp展现了MCP技术的几个显著优势,这对于开发来说,可以用自然语言方式执行命令和调试bug:
- 高效令牌使用:模型只需关注输出中的关键部分,即使长时间运行的命令,通常也只需分析最后几行输出,极大提升了效率。
- 自然集成体验:用户与模型共享iTerm界面,可以随时询问屏幕内容或委托任务,实时观察模型的执行过程。
- 完整的终端控制:支持启动并交互式操作REPL,能够发送ctrl-c、ctrl-z等控制指令。
- 低依赖设计:通过npx即可运行,依赖极简,便于集成到Claude Desktop等MCP客户端。
但使用这个功能有极大的安全隐患
iterm-mcp通过AppleScript实现MCP向iTerm2发送指令,虽然需要用户授权,但这种机制仍存在明显风险。试想,如果恶意MCP发送rm -r /tmp
等危险指令,用户将面临灾难性后果,更重要的是,这个问题是所有mcp都存在的,这种潜在风险不容忽视。
基于当前安全状况,几点想法:
-
目前MCP仅作为尝鲜使用,不要尝试未经验证的服务
-
必须严格审查每条指令,注意查看提示,不要瞎确认
-
切勿开启自动审批功能,现在很多客户端有builder 模式,就是智能体模式,声称可以自动完成任务,这类功能通常需要依赖本地文件读写,一般也具备本地文件删除能力,尽量使用云服务吧。
二、MCP安全现状与行业趋势
当前的讨论已经引发社区对MCP安全的高度关注,华中科技大学3月在arxiv发表一篇《Model Context Protocol (MCP): Landscape, Security Threats, and Future Research Directions》介绍了 MCP 服务器的关键组件,并定义了其生命周期,包括创建、运行和更新阶段,还强调了每个阶段可能存在的安全风险,并提供了关于保护 AI 与工具交互的展望。亚马逊AWS与Intuit旗下对抗性AI安全研究团队(A2RS)4月也发布了《Enterprise-Grade Security for the Model Context Protocol (MCP): Frameworks and Mitigation Strategies》,建立在Anthropic官方MCP协议规范及前期安全研究的基础上,这个研究得到美国国家标准与技术研究院(NIST)相关项目的理论支持。
目前MCP发展轨迹与早期Docker的情况颇为相似——大量未经验证的镜像声称"即装即用",但用户极少检查Dockerfile或源代码。预计未来1-2年内,MCP生态将逐步规范化,可能出现类似"MCP Hub"的中央仓库,理想情况下应由Anthropic等权威机构主导,但以Google的调性,绝对会想搞出类似k8s一样的东西,感觉Agent2Agent就是这个目的,未来会有MCP编排、Agent编排工具等。
三、核心安全问题剖析
1. npx执行风险,未来需要服务签名保证安全
常见的npx <包名>
启动方式会直接安装最新版并执行package.json定义的操作,绝大多数用户不会检查代码内容。如果上游存在恶意代码,后果不堪设想。相对而言,node index.js
需要手动构建,但仍需验证安装源的可信度。
2. 智能体终端控制机制风险,未来使用沙箱运行会更好控制权限
类似iterm-mcp通过AppleScript操控iTerm2,用户一旦授权就等于允许任意指令执行。目前Cursor、Windsurf、Cline等工具已探索两个月,通过白名单机制限制可执行命令。期待iterm-mcp引入类似机制,甚至默认在Docker容器中以普通权限运行指令。预计一年内会出现兼顾安全与便利的成熟方案。
3. 云服务商布局,运行在云端,由企业对安全进行维护对用户最好
MCP Hub出现后,AWS等云厂商很可能推出自家托管服务(类似ECR容器仓库),最快可能于年底前实现,但市场变化速度难以准确预测。国内阿里已经发布了相关平台,甚至提供了支付宝的MCP实现,换句话说,AI-Agent可以花你的钱了!!!这又是更大的安全问题!!
四、当前最佳实践与未来展望
基于安全考虑,目前阶段不要使用未经安全验证的包,尽量选择Anthropic/Smithery官方包,主流风险较小。从长远来看MCP服务应由供应商托管(仅暴露接口),目前3月26日新版本协议就有这种趋势,最引人注目的革新之一 Streamable HTTP 传输机制,这利好于基于云的MCP服务,因此本地运行服务应视为过渡方案。
对于MCP未来一年的发展,我做出以下预测:
- 基于云的MCP服务成为重点,MCP与Serverless有相同的技术特征,可以快速发展
- 安全规范将加速建立(如数字签名验证、沙盒隔离)
- 权限分级和操作审计成为标配
- 可能出现"可信MCP"认证体系
- 可能出现服务于普通用户管理权限的工具箱
- 企业级场景将推动混合云部署模式
MCP技术的发展方兴未艾,Google又带来了A2A,安全与便利的平衡将是一个持续优化的过程,但是技术仍在不断进步,终将带来更好体验。
题外话
顺便不得不说一下开头提到我实现的网关代理工具,嗯,清明节用是Rust语言写的,性能非常高,21年老苹果电脑的M1 pro 芯片QPS能到30000(每秒处理3万个请求),原理也很简单,未来会加入权限管理、流量控制等一系列安全工具研究成果github.com/sxhxliang/m…