> ## Documentation Index
> Fetch the complete documentation index at: https://mcp-zh.com/llms.txt
> Use this file to discover all available pages before exploring further.

# SEP-1024：面向本地服务器安装的 MCP 客户端安全要求

* **状态（Status）**: Final
* **类型（Type）**: Standards Track
* **创建（Created）**: 2025-07-22
* **作者（Author(s)）**: Den Delimarsky
* **Issue**: #1024

## 摘要

本 SEP 针对支持一键安装本地 MCP 服务器的 MCP 客户端实现中的关键安全漏洞。当前的 MCP 规范缺乏针对客户端安装流程的明确安全要求，使得恶意行为者能够通过经由链接或社会工程分发的、精心构造的 MCP 服务器配置，在用户系统上执行任意命令。

本提案为 MCP 客户端确立一项最佳实践，要求在执行任何本地服务器安装命令之前获得明确的用户同意，并保证命令的完全透明。

## 动机

现有的 MCP 规范未处理与精简化（"一键式"）本地服务器配置相关的客户端安全关切。当前实现这些配置体验的 MCP 客户端制造了显著的攻击向量：

1. **静默命令执行**：MCP 客户端在通过一键流程安装本地服务器时，可以自动执行内嵌命令，而无需用户审阅或同意。

2. **缺乏可见性**：用户对其系统上正在执行什么命令毫无洞察，这为数据窃取、系统入侵和权限提升创造了机会。

3. **社会工程漏洞**：用户逐渐习惯于执行标记为"MCP 服务器"的命令而不加适当审查，使他们易受恶意配置侵害。

4. **任意代码执行**：攻击者可以在 MCP 服务器配置中内嵌有害命令，并通过合法渠道（仓库、文档、社交媒体）分发它们。

Visual Studio Code 通过实现同意对话框[解决了这一问题](https://den.dev/blog/vs-code-mcp-install-consent/)。类似地，Cursor 也为一键安装本地 MCP 服务器支持同意对话框。

如果规范中没有明确的安全要求，MCP 客户端实现者可能会在不知情的情况下创建易受攻击的安装流程，使终端用户面临系统被入侵的风险。

## 规范

### 客户端安全要求

支持一键式本地 MCP 服务器配置的 MCP 客户端\*\*必须（MUST）\*\*实现以下安全控制：

#### 配置前同意

在执行任何用于安装或配置本地 MCP 服务器的命令之前，MCP 客户端**必须（MUST）**：

1. 显示一个清晰的同意对话框，其中展示：
   * 将要执行的确切命令，不加截断
   * 所有参数
   * 一条明确的警告，说明此操作可能存在潜在危险

2. 通过一个肯定性操作（点击按钮、勾选复选框等）要求用户明确批准

3. 为用户提供取消安装的选项

4. 在同意被拒绝或未提供时不继续安装

## 理由

### 设计决策

**强制性同意对话框**：要求明确的同意对话框在安全性与可用性之间取得平衡。虽然这为 MCP 服务器配置过程增加了摩擦，但它防止了静默命令执行导致的潜在破坏。

## 向后兼容性

本 SEP 为 MCP 客户端实现引入了新的**要求**，但不改变核心 MCP 协议或线路格式。

**影响评估：**

* **低影响**：既有 MCP 服务器和核心协议保持不变
* **需要客户端实现**：MCP 客户端必须更新其本地服务器安装流程以符合新的安全要求
* **用户体验变化**：用户将看到此前不存在的同意对话框

**迁移路径：**

1. MCP 客户端可以在新版本中实现这些更改，而不破坏既有功能
2. 既有已安装的 MCP 服务器继续正常工作
3. 只有新的安装流程需要同意机制

不存在协议层面的向后兼容问题，因为本 SEP 针对的是客户端行为，而非 MCP 线路协议。

## 参考实现

不适用

## 安全影响

### 安全收益

本 SEP 直接针对：

* **任意代码执行**：防止静默执行恶意命令
* **社会工程**：迫使用户在执行前有意识地审阅命令
* **供应链攻击**：为 MCP 服务器安装命令创造可见性
* **权限提升**：用户可以识别并拒绝请求提升权限的命令

### 残留风险

即便有这些控制，风险仍然存在：

* **用户覆盖**：用户可能无视警告批准恶意命令
* **精巧的混淆**：高级攻击者可能构造出看似合法的命令
* **实现缺口**：客户端可能错误地实现这些控制

### 风险缓解

这些残留风险通过以下方式应对：

* 同意对话框中清晰的警告措辞
* 建议增加额外的安全层（沙箱、签名）
* 持续的安全研究和社区意识