MCP 排错日志里的凭据泄露隐患

MCP 日志应该告诉我哪里出了问题，并提供足够的调试信息。如果它连请求中附带的 access token 也一起交了出来，那就麻烦了。

一次 OAuth 失败就可能越过这条界线，甚至不需要有人刻意记录 token。URL 的查询字符串里可能带着 secret，表单请求体里也可能有。随后，错误处理逻辑把请求复制进错误消息，而你又把这条消息粘贴到了 issue 中。

为什么调试工具会变成凭据存储库？因为复制出去的错误信息，会比你试图修复的那次短暂会话存在得更久。

MCP Inspector 2.9.0 就提供了一个值得研究的案例。

modelcontextprotocol / inspector

用于 MCP server 的可视化测试工具

这是一个用于检查 Model Context Protocol（MCP）server 的开发者工具。它以单个软件包 @modelcontextprotocol/inspector 分发，提供四种检查 server 的方式：

Web — 基于 Vite + React + Mantine 的单页应用，配有 Node 后端。

CLI — 可编写脚本的命令行客户端，适用于自动化、CI，以及需要快速反馈的 Agent 工作流程。

TUI — 使用 Ink 构建的交互式终端 UI。

mcpdo（实验性）— 用于管理连接的 CLI：连接一次后，就可以通过隐式运行的本地 daemon，对命名连接执行多条命令。参见 clients/mcpdo。

前三种方式都通过同一个全局 mcp-inspector 可执行文件运行；mcpdo 则是同一软件包中的第二个可执行文件：

npx @modelcontextprotocol/inspector                   # web UI (default)
npx @modelcontextprotocol/inspector --cli             # CLI
npx @modelcontextprotocol/inspector --tui             # TUI
npx -p @modelcontextprotocol/inspector mcpdo --help   # mcpdo

Inspector 会管理 OAuth token、OAuth client secret 和 stdio env: 的值等 secret，并将它们存储起来……

这个版本将获取到的 OAuth token 移入 secret store，并修复了 CLI 错误封装中 URL 查询参数里的 secret 脱敏问题，以及已记录请求体中表单 secret 的脱敏问题。其中一项修复针对的是这样一种情况：表单 secret 的尾部被一个未经编码的 & 拆开了。这些细节告诉我们，审查自己的 MCP 工具时该检查哪些地方：存储、错误文本和请求记录，对 secret 的处理方式未必相同。

检查你即将分享的材料

在把 Inspector 日志、终端录屏或 tool-call trace 附到公开 issue 之前，先检查即将离开你电脑的那份副本。如果准备分享的是底层文件，就不要因为 UI 中显示得让人放心而掉以轻心。

先看 URL。保留 endpoint、状态，以及某个 OAuth 步骤失败这一事实。在把 URL 粘贴到任何地方之前，先移除查询参数中的凭据。也要检查错误消息：它们可能直接引用 URL，而不是把 URL 放在单独的请求字段里。

接着，检查请求体和响应体。表单数据尤其值得仔细检查，特别是在错误记录中包含原始请求体时。脱敏代码必须能够处理不规范的输入，Inspector 针对原始 & 的修复就说明了这一点。某个字段在一个视图里看起来已经被遮蔽，并不能证明所有记录副本都做了遮蔽。

然后，检查 token 在两次运行之间存放在哪里。Inspector 2.9.0 会将获取到的 OAuth token 保存在 secret store 中，但存储本身也需要单独审查。发布说明记录了一个已知问题：共用同一个 server 的 OAuth profile，可能会相互覆盖 token。如果你通过 MCP_INSPECTOR_OAUTH_STATE_PATH，为同一个 server 使用不同的 profile，发布说明建议为每个 profile 配置独立的 secret store：设置 MCP_INSPECTOR_SECRET_STORE=file，并分别指定不同的 MCP_INSPECTOR_SECRET_FILE；或者为每个 profile 配置独立的 MCP_STORAGE_DIR。默认的单 profile 配置不受影响。

最后，凭据一旦暴露，就要按已经泄露来处理。事后从 issue 评论里删掉它，并不能让它从此前的通知、下载文件或复制出去的 trace 中消失。应通过服务提供方撤销或轮换凭据，再用脱敏后的版本替换已经分享的材料。

MCP 是 Agentic AI Foundation 旗下的开源项目之一。它的工具本就应该接受公开检查、测试和讨论。你应该能够报告失败的 OAuth 步骤，以及导致失败的响应，而不必顺手把一份仍然有效的凭据交给下一位读者。保留诊断细节，去掉 token。

如果要采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。