奇 奇连 AI
学习路线图课程工具计算器企业服务关于加入会员

装插件前先看这一页：Cursor 官方文档对 Marketplace 安全的说明

2026-08-18

同事在群里丢了个 Marketplace 里的插件链接，问「这个能装吗」。这种问题最难答的地方在于，多数人凭印象答——「官方市场的应该没问题吧」。官方文档其实把话说得比这直白得多，而且直白的方向和很多人的印象是反的。

先把那页的口径抄准，再走一遍最常见的排查场景。

官方那页到底承诺了什么、没承诺什么

Cursor 官方帮助文档《Marketplace security》（cursor.com/help/security-and-privacy/marketplace-security）写明的要点，按原文口径列一下：

  • 上架前人工审核：每个上架 Marketplace 的 plugin 都会经过人工审核，审核维度写的是安全性、数据处理和质量。
  • 更新同样要审核：文档写明 Marketplace 里的 plugin 不会从源码自动更新，每次更新都要人工复审，没有显式批准就进不了 Marketplace。这一条值得单独拎出来看：依赖供应链的风险往往不在第一次安装，而在后续的版本更新（这是通用的供应链安全常识，不是这一页文档写的内容）。
  • 必须开源：所有 Marketplace 插件都必须开源，官方在同一页里直接给了建议：安装前自己看一遍源码。
  • 风险归属写得很明确：原文的措辞是 plugins 属于第三方软件，安装与否由安装者自行决定并自行承担风险。这不是免责话术式的一笔带过，它就写在「安装一个 plugin 有什么风险」这个小标题下面。
  • 形态上的风险面：文档说 plugin 在设计上是轻量的，主要是 markdown 文件以及 skills 需要的模板、脚本这类配套文件，不分发二进制。
  • 出事就先下架：一旦官方通过自身审核、社区报告或持续监控判定某个 plugin 对用户构成风险，会在问题解决期间立刻将其从 Marketplace 移除。
  • 作者有维护义务：插件作者被要求响应并解决上报的安全或稳定性问题，做不到的作者可能失去良好状态，其插件可能被下架。
  • 报告渠道：发现问题发到 security-reports@cursor.com。
  • 目前是策展制：文档自述 Marketplace 保持 curated，只与信任的作者直接合作，并写明随着审核标准成熟「计划」更广泛地开放。这句是文档写的规划，不是已生效的能力。

注意这里面没有的东西：没有承诺插件不会出问题，没有承诺审核能发现全部问题，也没有给出审核的具体标准清单。所以真正落到你手上的动作只有两个——看源码，以及把插件能碰到的东西提前限死。后者就是下面这段排查的主线。

现象：插件装上了，它带的 MCP server 一个调用都发不出去

这个现象在官方文档里有一句几乎是逐字对应的说明。《Marketplace security》页写明：plugin 会遵守你的 MCP allowlist 与 blocklist，只能访问你已明确允许的工具和服务器；如果一个 plugin 里含有被拦截的 MCP server，它仍然会正常安装，但那个被拦的 server 无法发起调用。同页还写明，既有的 MCP 治理策略会自动延续过来，不需要额外配置。

所以这个现象长这样：按文档口径插件本身是正常安装的，它带的 rules、skills 之类的部分照常存在，唯独被拦下的那个 MCP server 发不出调用。安装环节也不会给出失败信号——因为按文档写明的行为，它本来就该装成功。

怎么确认是这个问题

判定动作分三步，都可以在不改任何配置的前提下先做完。

第一步，先确认这台机器上到底有没有生效中的 allowlist，以及它来自哪一层。 官方文档《Model and integration management》（cursor.com/docs/enterprise/model-and-integration-management）写明，Cursor 解析生效的 MCP allowlist 有固定顺序：

  1. 团队 dashboard 或其它管理员控制的设置
  2. ~/.cursor/permissions.json
  3. 编辑器设置里的 MCP allowlist，以及行内的 Add to allowlist（按钮名为官方文档写明）

这里有个容易踩的点，文档一句话说得很清楚：高优先级来源会替换低优先级来源，它们不合并。也就是说你在编辑器设置里加的那条，在管理员下发了 allowlist 的机器上根本不参与运算。排查时如果只盯着自己改过的那一层看，会得出「我明明加了」的错误结论。

同页还写明，allowlist 一旦生效，只有匹配到条目的 server 能运行，不匹配的一律被拦。这就是默认拒绝的语义——不是「没写进黑名单就能跑」。

第二步，看这个 server 在 mcp.json 里是命令型还是 URL 型，两种的匹配对象完全不同。

对命令型（stdio）的 server，文档写明 allowlist 匹配的是完整命令串：command 的值和 args 里所有值用空格拼起来。文档给的示例配置是：

{
  "mcpServers": {
    "my-tool": {
      "command": "npx",
      "args": ["-y", "@acme/mcp-tool@latest"]
    }
  }
}

拼出来是 npx -y @acme/mcp-tool@latest。但文档紧接着提醒，多数系统上 shell 会把 npx 解析成完整路径，实际参与匹配的串会变成带路径的那一串，文档举的例子是 /usr/local/bin/npx 和 /opt/homebrew/bin/npx。

Windows 侧要额外留一句：上面两个都是类 Unix 路径，官方文档没有给出 Windows 上对应的路径写法，也没有说明 Windows 上完整命令串会被解析成什么样子。所以如果你在 Windows 上照着「写精确路径」的思路配 allowlist，很容易配出一条永远匹配不上的条目。文档给出的规避办法对 Windows 用户尤其适用——用前导 * 通配掉安装路径，例如文档表格里逐字给出的这几种写法：

allowlist 条目文档写明的匹配范围
*npx -y @acme/mcp-tool@latest任意路径下的 npx，参数完全一致
/usr/local/bin/npx -y @acme/mcp-tool@latest只匹配这一个精确路径
*npx -y @acme/*任意 @acme 作用域下的 MCP 包
*python */scripts/mcp-server.py*任意匹配路径下的 Python server，后面可带任意参数

对 URL 型（HTTP/SSE）的 server，文档写明匹配对象是完整 URL，支持 https://*.acme.com/* 这种子域加路径的通配，也支持只写精确 URL。

第三步，确认拦的是「server 层」还是「tool 层」。 文档写明每个已批准的 server 还有各自的工具控制，位于 MCP Configuration 区域，按 server 设置而不是放在单独的自动运行列表里：在该 server 的 Tools 字段里列出允许运行的工具，留空表示允许该 server 的全部工具。如果 server 本身在 allowlist 里、却只有某几个工具不动，方向就该从 server 匹配转到这个字段上。

文档语义给出的处置

写 allowlist 条目时可用的语法，文档给的是 server:tool 形式，一共四种组合：

条目含义
server:tool某个 server 上的某个具体工具
server:*某个 server 的全部工具
*:tool任意 server 上叫这个名字的工具
*:*全部 MCP 工具

~/.cursor/permissions.json 里的 mcpAllowlist 必须是字符串数组，文档还写明这个文件可以通过 MDM 下发，用来设定每用户的 MCP 自动运行 allowlist。需要注意的是，团队 dashboard 里的 MCP Configuration 按文档标注是 Enterprise 限定（原文标的是 Enterprise only），不在这个计划上就没有这一层。

Cursor CLI 侧是另一套写法。官方文档《Permissions》（cursor.com/docs/cli/reference/permissions）写明权限令牌配置在 ~/.cursor/cli-config.json（全局）或 <你的项目目录>/.cursor/cli.json（项目级），MCP 相关的令牌格式是 Mcp(server:tool)，同样支持 * 通配：

{
  "permissions": {
    "allow": ["Mcp(*:search)"],
    "deny": ["Mcp(*:*)"]
  }
}

以上为按官方文档中的参数语义组合的示例，未经实测，以官方文档与 --help 的实际输出为准。同页写明 deny 规则优先于 allow 规则，这一条在排查「我明明 allow 了」时经常是答案。

顺带说一处口径差，是我把两页放在一起看才注意到的：《Marketplace security》页的措辞是 plugin 遵守你的 MCP「allowlist 和 blocklist」，但企业侧那页描述的机制里并没有一个独立的 MCP blocklist 配置项，只有 allowlist 加上「不匹配即被拦」；CLI 那边则确实有 permissions.deny。两页的词不完全对得上，具体以你实际用的那一端的文档为准，别按帮助页那句话去找一个叫 blocklist 的开关。

网络这一层文档也给了口子：每个已批准的 server 有独立的网络策略，远程（URL）server 被限制在配置的 URL 条目模式内；本地命令型（stdio）server 在 sandbox 里运行，网络模式共四档——Allow all（无出网限制）、Allowlist（只能到列出的目的地）、Deny all（本地运行、无出网）、No sandbox（不做命令与网络沙箱）。最后一档是明确关掉沙箱的选项，选它之前要清楚自己在关什么。

处置后怎么验证

改完别只看「调用通了」，这几点文档写明了，值得逐条对一遍：

  • 改的是不是生效中的那一层。前面那个替换而非合并的顺序，回头再确认一次。
  • allowlist 里有条目 ≠ 团队成员机器上就有这个 server。文档写得很直接：把 server 加进 allowlist 并不会把它推到用户机器上，成员仍需在自己的 Cursor 设置里配置。要真正分发，文档给的路径是加到 team marketplace。
  • 逐次批准这层还在。官方文档《Agent Security》（cursor.com/docs/agent/security）写明：所有 MCP 连接都需要你批准，批准连接之后每一次工具调用仍需单独批准，除非用 MCP allowlist 预先批准了特定工具。所以「配了 allowlist 还在弹批准」不一定是没生效，可能只是你批准的粒度不对。
  • 同页还写明，Cursor 的这些护栏是默认行为，官方的建议是保持启用；Run Modes 从简单的 allowlist 到 Auto-review 分类器都有，但原文明确称其为尽力而为的护栏，而不是硬性的安全边界。这句话的分量比它的长度大，抄配置的时候别把它跳过去。

什么情况说明不是这个原因

这一步最容易被省，但省了就会在错的方向上耗一下午。以下几种情况，基本可以排除「被 MCP allowlist 拦了」：

  • 插件的 rules、skills、commands 也一起没生效。MCP 拦截只拦 MCP 调用，按文档口径插件本身是正常安装的。整包都不动，更像是插件没装上或作用域选错——文档写明安装时要选 project 或 user 作用域，本地开发时插件从 ~/.cursor/plugins/local 加载。
  • 卡住的是终端命令而不是 MCP 工具。终端命令默认需要你批准，归 Run Modes 管，和 MCP allowlist 是两套东西。
  • 仓库整体不可用。企业侧有 Repository Blocklist（文档标注 Enterprise only），被加进去的仓库 Cursor 会拒绝索引或处理，那是仓库层面的问题，不是插件层面的。
  • 文件根本读不到。.cursorignore 会挡住 agent 对特定文件的访问，这条和 MCP 无关。
  • 你不在 Enterprise 计划上。团队 dashboard 的 MCP Configuration 是 Enterprise 限定，那台机器上压根不存在管理员下发的那一层，排查该转到本机 ~/.cursor/permissions.json 与编辑器设置。

最后回到最开头那个问题。文档能给你的确定性只有「上架和每次更新都过人工审核、必须开源、出事会下架」，其余全部落在你自己身上：装之前看源码，装之后用 allowlist 与 per-server 的工具、网络控制把它能碰到的面缩到最小。官方那页把风险归属写在明面上，不是客套。

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。 该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。 该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。 本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。 安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。

想系统学会用 AI？报名体系课或加入会员，照着学、照着用。

浏览课程 加入会员