在现代人工智能技术迅猛发展的背景下，模型上下文协议（MCP）成为连接大型语言模型（LLM）与第三方服务的重要桥梁。然而，伴随着MCP的广泛应用，凭证存储安全问题也愈发显现，成为威胁整个AI应用生态安全的关键隐患。许多MCP环境为了方便服务调用，会将长期API密钥明文保存在本地文件系统中，且往往带有过于宽泛的访问权限，导致一旦本地文件泄露，攻击者便可轻松获取关键凭证，进而入侵相关服务和数据。 持续观察表明，MCP凭证存储的不安全做法广泛存在于生态体系中。从官方的MCP服务器连接GitLab、Postgres、Google Maps，到第三方工具如Figma连接器和Superargs包装器，都暴露出类似的安全隐患。攻击者无需复杂的漏洞利用，只需要获取文件读取权限便能窃取API密钥，威胁范围涵盖本地乃至云端的多个环节。
本地恶意软件成为最直接的威胁。多种用户级恶意程序具备扫描常见配置文件路径的能力，如macOS下的~/Library/Application Support/及~/.config/目录，或应用日志目录等。这类恶意软件能够自动遍历这些路径，检索明文存储的API密钥并将其外泄。除恶意软件外，其他软件存在的任意文件读取漏洞同样可能为攻击者打开窃取凭证的方便之门。此外，在多用户环境下，若凭证文件权限设置不严，其他有文件系统访问权限的用户亦可窃取凭证。而云端备份策略若未妥善配置，也可能在无形中将敏感服务器配置文件同步至云存储，暴露给第三方服务提供商或其他用户。
MCP服务器需要凭证连接第三方API以实现数据读写操作。MCP于2025年3月修订引入OAuth 2.1，这种基于令牌的认证方式若得到正确实现，能有效实现短期、权限受限的凭证管理，极大降低长期凭证被窃取的风险。然而，在现阶段，不少下游服务尚未支持OAuth认证，迫使许多MCP工具依赖长期API密钥。API密钥通常通过两种主要渠道入驻MCP服务器：其一为存在于配置文件或环境变量中的明文密钥；其二为用户通过AI聊天界面直接输入凭证信息，再由模型传递给MCP服务器。两者均存在显著安全风险。 以配置文件为例，许多MCP服务器通过命令行参数或环境变量获取密钥。
这些变量往往从托管应用的配置文件中导入。如Claude Desktop软件，其会在用户主目录下生成claude_desktop_config.json文件，在macOS系统上，该文件默认权限为-rw-r--r--，意味着任意系统进程或用户均可读取其内内容。文件内若存储有明文API密钥，势必导致凭证暴露。 另一风险途径来自用户直接在AI聊天界面中输入凭证。Supercorp的Superargs包装器就明确支持这一行为，以便将凭证作为参数传递至MCP服务器。但这同样带来两重隐患。
首先，如前文所述，恶意MCP服务器可能通过会话历史窃取敏感信息。其次，聊天应用通常为调试和历史保存目的，会将完整对话内容记录成日志文件。若这些日志文件默认同样设为世界可读权限，攻击者便可轻易访问包含凭证的对话记录。测试中发现，应用如Cursor和Windsurf均存在如此问题，日志目录及文件权限宽松。 以Figma社区MCP服务器为例，问题尤为严重。该服务器通过Node.js的fs.writeFileSync函数写入用户API密钥至配置文件，而此函数默认创建权限为0666（-rw-rw-rw-），即世界范围内可读写。
该漏洞不仅使凭证泄露易如反掌，攻击者还可借此进行会话固定攻击，诱使用户登录恶意控制的设计账号，导致机密设计稿等敏感信息外泄，若是金融类服务，还可能引发财务转移等严重后果。 为了解决上述挑战，整个生态系统需共同推进安全改进措施至关重要。首先，所有具有公开API的第三方服务应积极实现OAuth支持，借助其短期令牌及粒度权限控制，提升整体安全性与用户体验。通过浏览器登录等友好方式，不仅避免用户手工配置复杂文件，亦大大减少长期凭证泄露风险。对于尚不支持OAuth的服务，MCP服务器开发者应采纳更安全的凭证存储方式。现代操作系统皆提供专门的凭证管理API，如Windows的凭证管理器、macOS的钥匙串服务。
这些API自动对凭证进行加密储存和权限管控，远优于明文文件存储。 用户方面，鉴别并审慎选择安装的软件极为重要。应优先使用支持OAuth认证或利用安全操作系统API管理凭证的MCP服务器。对于暂时无法避免的明文文件存储用户，尽可能手动收紧文件权限，防止无关用户或进程访问敏感信息。 当前AI与MCP技术迅速演化，研发者常将功能扩展置于安全之前。然而，MCP已然成为推动更强大AI系统的关键基础，若安全问题被忽视，其带来的威胁将不可估量。
为保护整个生态系统的健全发展，安全凭证管理必须从设计伊始就被置于核心地位。通过行业推动完善认证机制、倡导安全存储实践及用户教育，多方协作才能筑牢MCP环境的安全防线。 未来，随着MCP生态日益丰富复杂，凭证安全仍将是重点防护对象。只有持续关注并改进，才能为AI应用创造一个既强大又安全的运行环境，防止数据和资产遭受恶意侵害。
