MCP 配置怎么做安全检查？Secret、Shell 与权限实测

MCP 配置真正容易留下长期风险的地方，往往不是 JSON 少了一个逗号，而是能正常运行、所以一直没人回头检查的权限和凭据边界。最常见的几类包括：把真实凭据写进配置、给 Shell 过大的命令范围、把 Remote MCP 当成普通 URL 信任、日志里保留认证信息，或者一个只需要读取数据的 Agent 却拿到了写权限。

这类检查适合在部署前做静态扫描，但要避免另一种极端：看到 command、shell、env 就一律判高危。安全判断必须结合实际执行边界。

MCP 配置中的高风险项总览：明文凭据、文件系统、Shell、网络、环境变量与授权边界

第一类：明文 Secret

危险的不是出现环境变量名，而是把真实值塞进可能提交、复制或截图的文件。安全的配置应该只保存变量引用或凭据标识，真实值由受控运行环境注入；文档、Issue、截图和示例里统一使用脱敏占位符。

MCP 授权规范明确区分了 HTTP 和 stdio 场景：stdio 不应该照搬 HTTP OAuth 流程，而应从环境等受控位置获取凭据。远程 HTTP Server 则需要按 OAuth、Protected Resource、资源绑定和权限范围处理授权，而不是把一个长期凭据复制到所有客户端。

部署前至少确认：配置文件是否进入版本控制、错误日志会不会打印认证字段、CI 是否把秘密写入构建产物、示例配置会不会被用户直接复制到公开仓库。

危险 MCP 配置与安全配置对比：明文凭据、环境变量、文件权限、Shell 与网络边界

第二类：Shell 不是原罪，过宽 Shell 才是问题

下面两种执行边界的风险完全不同：

固定程序 + 固定工作目录 + 受控参数

和：

通用命令解释器 + 模型直接拼接参数 + 高权限执行身份

所以扫描器看到 bash、sh、powershell 或其他命令执行能力后，应该继续问：

参数来源是不是用户或模型可控；
是否限制工作目录；
是否允许任意网络、文件系统和子进程；
执行身份是否超出任务所需；
写操作是否需要确认；
命令和结果是否进入日志。

仅靠字符串匹配无法证明漏洞，但可以把值得人工复核的边界找出来。

最小权限原则：从配置文件、Agent、工具层到文件系统 Shell 网络和数据库的权限边界

第三类：Remote MCP 是信任边界

一个 Remote MCP URL 不只是“另一个 API 地址”。连接后，Agent 可能获得远程提供的 Tools、Resources 或 Prompts，因此至少要确认：

域名和文档是否来自预期提供方；
是否使用 HTTPS；
授权凭据是否只发给目标资源；
Scope 是否最小化；
Tool 描述或远程返回内容是否会直接进入模型上下文；
断开或更换提供方后权限是否能撤销。

Notion 的 MCP 安全指南也明确建议先核对官方 endpoint，并提醒连接 MCP 相当于把对应用户权限暴露给使用该连接的 AI 系统。远程端点如果还需要做协议、目录和鉴权边界预检，可以接着使用 MCP Server 只读 Preflight，把配置风险检查和协议可用性检查分开。

第四类：日志和 Retention

即使模型提供商开启了某种数据控制，也不能推导出你的 MCP Client、Agent Memory、Trace、Application DB 和日志全部零留存。

配置检查时要单独看：

是否记录认证 Header；
Tool 参数里有没有敏感字段；
错误日志是否原样打印请求；
Trace 平台保存多久；
本地缓存、Memory、Vector Store 有没有清理策略。

这也是 OpenAI ZDR 与 Agent 数据边界实测里强调过的区别：Provider 侧控制和端到端 Agent 留存不是同一件事。

MCP 配置风险等级矩阵：Critical、High、Medium 与 Low 的典型场景和处理建议

用 Agent Security Auditor 做一次本地检查

XBSTACK Agent Security Auditor 的定位是浏览器本地静态扫描。你可以贴入已经脱敏的 MCP/Agent 配置或代码，工具会从 Secret、Shell、Remote MCP、权限、Retention、日志和执行上限等维度给出 finding 和证据。

推荐流程：

1. 复制配置前先脱敏真实凭据
2. 本地扫描
3. 按 finding 定位具体字段
4. 判断是实际风险还是有边界的合理配置
5. 修改配置
6. 再扫一次，保存整改前后结果

这里的关键是“证据 + 人工判断”。例如一个固定只读脚本使用 bash，扫描器可以提醒 Shell 边界，但最终不能仅凭 bash 字符串断言它存在任意命令执行漏洞。

MCP 配置安全审计流程：读取配置、识别 Secret、权限分析、规则匹配、输出修复建议和复审

Agent Security Auditor 审计结果面板：风险等级、主要发现与修复建议

一个部署前检查表

[ ] 配置和仓库中没有真实凭据
[ ] Remote MCP endpoint 与官方文档一致
[ ] HTTP 授权的资源与权限范围匹配
[ ] Shell/command 参数来源受控
[ ] 文件和网络权限不超过任务需要
[ ] 写操作有确认或业务授权
[ ] 日志不会记录 Secret
[ ] Trace/Memory/DB Retention 有明确期限
[ ] 第三方 MCP/依赖来源可追踪
[ ] 测试和生产凭据分离

如果其中几项答不上来，优先补边界，而不是继续加更多 Agent Tools。

MCP 配置修复前后对比：从明文凭据和宽权限收敛到环境变量与最小权限

当前结论

MCP 配置安全不是“把所有 command 删除”或者“只要用了 OAuth 就安全”。真正需要管理的是凭据在哪里、谁能调用什么、以什么身份执行、数据会留在哪里、远程能力来自谁。

Agent Security Auditor 能做的是把这些配置级信号快速暴露出来，减少人工漏查；完整生产安全仍然需要代码审查、运行时权限、服务端鉴权、依赖治理和业务测试共同完成。

专题入口 / MCP Hub

继续按 MCP 生产部署路径读，而不是堆 guide / tutorial

MCP 内容统一按协议理解、本地 Server、远程部署、OAuth、安全治理、stdio/JSON-RPC 排障和工具对比来承接，避免站内关键词互相抢。

进入 MCP 专题 → 查看安全治理清单订阅

小白 / Xiaobai

MCP 配置怎么做安全检查？Secret、Shell、Remote MCP 与权限边界实测