TL;DR：随着AI代理能够直接与生产基础设施交互，MCP服务器正成为新的安全边界。若组织继续依赖静态凭证和宽泛权限，AI基础设施可能沦为高价值攻击目标，因此机密管理和机器身份治理至关重要。

AI已迅速超越辅助开发者编写代码的阶段。如今的AI代理能够排查生产系统故障、查询数据库、部署应用，并在最少人工干预下编排多步骤工作流。

MCP（模型上下文协议）通过为AI系统提供连接外部服务的标准化方式，加速了这一转变。然而，当大量讨论聚焦于提示注入或模型漏洞时，许多组织忽视了一个更根本的问题：使AI能够与真实基础设施交互的凭证。

随着AI成为现代环境中的运营层，机密管理正从DevOps关注点演变为AI安全的核心支柱。

MCP为何改变基础设施安全模型

MCP本身并无固有风险，挑战在于它集中了访问权限。

组织不再为每个工具创建单独集成，而是越来越多地部署MCP服务器，作为AI代理与云提供商、数据库、内部API及SaaS应用之间的请求代理。这极大简化了AI集成，但也创造了一个可访问多个系统的强大机器身份。

如果该身份依赖长期有效的API密钥或宽泛范围的凭证，一次单一泄露就可能暴露组织基础设施的很大一部分。

与传统自动化不同，AI代理并非仅执行预定义命令。它们解释请求、选择工具，并在多次交互中携带上下文。这意味着基础设施访问不再局限于明确的人类操作，而是越来越多地流经代表用户决策的自主系统。

对安全团队而言，这使信任边界从单个用户转向机器身份。

AI工作流创造机密暴露的新机会

传统机密管理主要关注防止凭证进入源代码和配置文件。

AI引入了多种新途径，使这些凭证可能泄露。

开发者在调试时经常将日志、配置片段和错误消息粘贴到AI助手中。这些片段可能包含API密钥、数据库凭证或连接字符串，由于从未进入版本控制或CI管道，它们绕过了传统安全控制。

AI驱动的工作流还引入了以下风险：

  • 提示注入攻击，操纵代理泄露敏感信息；
  • 存储在.env文件或配置文件中的长期凭证；
  • 权限过宽的MCP服务器，可访问多个生产系统；
  • 未经安全审查的公共或社区构建的MCP服务器；
  • 机密出现在提示、日志或训练数据集中，可能超出其预期生命周期而持续存在。

单独来看，这些问题并非新事物。但AI通过集中访问并增加敏感信息意外出现的场所，放大了其影响。

像对待任何特权身份一样保护AI代理

能够安全采用AI的组织，将把AI代理和MCP服务器视为一级机器身份，而非后台运行的普通应用。

这始于用动态访问取代静态凭证。

不应将机密嵌入代码或配置文件，而应在需要时才注入凭证，自动轮换，并限定其支持的具体工作负载。每个MCP服务器应仅拥有其用途所需的系统访问权限，以限制凭证泄露时的爆炸半径。

一个强大的AI安全模型还应包括：

  • 运行时机密注入，而非硬编码凭证；
  • 短期、自动轮换的令牌；
  • 每个MCP服务器的最小权限；
  • 跨AI操作和基础设施访问的集中审计日志；
  • 部署前对第三方MCP服务器进行安全审查。

这些实践并不能消除AI风险，但能显著降低不可避免的错误和配置失误所造成的影响。

AI安全正成为身份治理问题

随着AI代理成为软件交付中的永久参与者，组织需要以管理人类用户同样的严谨度来治理机器身份。

最大的安全挑战并非AI模型本身，而是确保每个AI驱动的系统都有明确定义的权限、临时凭证和完整的可审计性。

实际上，这意味着将机密管理视为AI基础设施的控制平面，而非仅仅是安全存储API密钥的地方。

早期投资于集中式机密管理、动态凭证和机器身份治理的组织，将更有能力拥抱AI原生工作流，而不会显著增加运营风险。随着AI采用加速，保护这些系统背后的身份可能远比保护模型本身更为重要。