MCP 让 Agent 变强，也让风险变大
如何安全地使用 MCP 服务器
MCP 是 AI 编程 Agent 的「USB-C」，但连接 GitHub、数据库、终端后，单个失控就可能泄露代码或执行危险命令。本文给出可落地的沙箱、最小权限与审计方案。
为什么 MCP 让安全问题更紧迫
传统工具调用是模型「请求你执行」，MCP 是模型「自己发现并调用你暴露的工具」。一旦 MCP 服务器权限过大，Agent 就能读取任意文件、改代码、推送到生产仓库。2026 年多 Agent 工作流普及后，安全团队开始把 MCP 列为重点攻击面。
MCP 常见风险模型
权限过宽
很多早期 MCP 服务器默认给完整文件系统或 shell 访问，Agent 一旦被提示注入就能做任何事。
影子 MCP
开发者或 Agent 自己临时写了个 MCP server 暴露内部服务，没有 review 就长期运行，变成隐形后门。
横向移动
一个被攻破的 MCP 往往连着多个资源（Git + DB + CI），攻击者可以快速横向拿到更多凭证和代码。
推荐的沙箱模式
生产环境永远不要让 Agent 直接操作宿主机。以下模式按隔离强度排序：
# 推荐：只读文件系统 + 网络白名单 + 进程隔离
# 生产 MCP 服务器应声明最小权限
tools:
- name: "read_only_fs"
permissions: ["read"]
- name: "git_read"
permissions: ["read", "status"]
# 避免直接给 write / exec 除非明确需要并加二次确认实际部署建议用容器（Docker / gVisor）+ 只读挂载 + 网络 egress 白名单。MCP 服务器自身也应做最小二进制与依赖。
落地最佳实践清单
- ●所有 MCP 服务器必须以低权限用户运行，并显式声明 tools 的读/写/执行范围。
- ●敏感操作（写代码、推送、执行测试）加入人类确认或二次审批步骤。
- ●开启完整审计日志，记录哪个 model、哪个会话、调用了哪个 tool 及参数摘要。
- ●定期 review 已连接的 MCP 列表，移除不再使用的服务器；用只读 token 代替长期个人 token。
在 QCode 上怎么更安全地用 MCP
QCode 提供统一 API Key + 中国低延迟接入。你可以在同一个 Key 下同时连接 Claude Code、Codex、Gemini 的 MCP 生态，同时在 dashboard 看到跨模型的调用记录，便于审计。所有 MCP 流量走 QCode 中转，不直接暴露你的原始密钥给第三方服务器。
MCP 安全常见问题
MCP 服务器必须自己写吗？用社区的安不安全？
社区服务器数量已超万级，质量参差。建议只用 star 数高、有公开源码和最近更新的；自己 fork 后加权限收紧再运行。绝不要直接给生产密钥。
沙箱会让 Agent 能力下降很多吗？
合理沙箱（只读 + 受限 exec + 网络白名单）对日常编码任务影响很小。真正的重构和测试执行仍可通过「请求人类确认」或受控 CI runner 完成，兼顾安全与效率。
MCP 流量经过 QCode 中转，会增加安全风险吗？
QCode 只做中转和配额管理，不持久化你的代码或文件系统。你的 MCP 连接仍由客户端发起，QCode 仅转发标准请求。配合最小权限 token，风险可控。
如何快速检查当前项目用了哪些危险 MCP？
在 Claude Code / Codex 里输入类似「列出当前所有已连接 MCP 服务器及其权限」的提示，结合 .mcp.json 或 config 文件 review；再去 QCode dashboard 按日期过滤可疑高权限调用。