众所周知，我最近在研究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：

1. 高效令牌使用：模型只需关注输出中的关键部分，即使长时间运行的命令，通常也只需分析最后几行输出，极大提升了效率。
2. 自然集成体验：用户与模型共享iTerm界面，可以随时询问屏幕内容或委托任务，实时观察模型的执行过程。
3. 完整的终端控制：支持启动并交互式操作REPL，能够发送ctrl-c、ctrl-z等控制指令。
4. 低依赖设计：通过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…