你的 MCP 允许列表里到底有什么?
摘要
提出对盲目信任 MCP 服务器允许列表而不审查工具模式的安全担忧,并将其比作 2013 年把 curl 管道传入 bash 的行为。
如今搭接 MCP 服务器感觉就像 2013 年把 curl 管道传入 bash。一个工具描述就是一个提示注入面,一个工具结果又是另一个注入面,而且我认为我们大多数人(至少我是这样)都是从注册表搜索中添加服务器,却不读一行它们暴露的内容。我自己本周的列表已经超过十几个服务器,我意识到我对它们的审查比我对一个 Chrome 扩展程序的审查还要少,这很能说明问题。而且权限模型对于每个服务器来说基本上是全有或全无,所以一个过于宽泛的工具会混入十个有用的工具中。有人在连接之前真的审查工具模式吗?还是我们都在信任并假设没有人会发布一个恶意的天气工具?
相似文章
你在安装 MCP 服务器之前实际上是如何审查它们的?
讨论在安装前缺乏对 MCP 服务器的审查,强调一项研究发现 5.5% 的工具被投毒,14.4% 存在已知漏洞模式,再加上 MCP SDK 中的一个系统性 RCE。
有人在开发者安装MCP服务器之前实际进行安全审查吗?
这是一个关于在开发者安装MCP服务器之前是否有人进行安全审查的问题,突显了AI工具生态系统中的潜在漏洞。
MCP安全现状 [pdf]
该PDF报告审视了模型上下文协议(MCP)的安全现状,涵盖漏洞与最佳实践。
MCP 服务器是否正在成为架构依赖?
引发了关于 MCP 服务器可能引入新的架构依赖的担忧,质疑绑定到特定服务器认证和实现的智能体是否真正可移植。
npm/Docker/PyPI的供应链安全模式正在MCP上重演,我们正处于2015年的时刻
文章警告称,MCP生态正在重演npm、Docker和PyPI中出现的供应链安全模式——审核极少,风险日益增长。文章指出,对500个Smithery服务器的扫描发现18.8%存在安全问题,现有安全工具无法处理恶意智能体指令,并介绍了一个名为bawbel的新型静态扫描器。