保护AI智能体：当AI工具从”读取”走向”执行”
导语：当企业AI智能体从”读取”内容转向”执行”动作，其背后的MCP工具供应链便成为新的攻击面。本文基于一个金融运营团队的真实场景，复盘了借助MCP工具描述投毒实现静默数据外泄的完整攻击链，并给出微软安全能力在检测、遏制与预防三阶段的落地控制措施。
随着企业级部署日趋成熟，部分企业AI智能体正从单纯”读取”内容转向”执行”动作。本文由微软事件响应团队撰写，剖析一种针对智能体AI供应链中增长最快环节的攻击模式：模型上下文协议（Model Context Protocol，MCP）工具。文章提供了利用微软安全控制来检测、遏制和预防此类攻击的实战操作手册。
这是AI应用安全系列的第三篇文章。系列第一篇《采用AI工具时的安全考量》探讨了AI的普及如何扩大企业攻击面；系列第二篇《检测与分析AI工具中的提示滥用》展示了间接提示注入如何影响被动式AI摘要器的输出。在上述两类场景中，AI仅读取内容并生成文本，并不执行动作。本篇文章则聚焦当这一边界发生变化时，会发生什么。
AI智能体可以规划多步骤任务、决定调用哪些工具，并代表用户执行操作。Microsoft 365 Copilot能够起草并发送电子邮件、创建文档、更新日历条目；Copilot Studio与Azure AI Foundry允许组织构建通过MCP连接业务系统的自定义智能体。随着AI越来越多地用于读写工作流，漏洞的影响特征也可能发生变化：针对摘要器的提示注入可能使输出产生偏差，而针对智能体的提示注入则可能触发具体的执行动作。
据国际数据公司（IDC）预测，企业中活跃AI智能体的数量将从2025年的2860万个增长至2030年的超过22亿。正是基于这一规模，2025年12月发布的OWASP智能体应用Top 10（即《OWASP Top 10 for Agentic Applications》）如今已与LLM Top 10并列，成为防御者的参考框架之一。本文聚焦其变化最快的类别之一：通过被投毒的MCP工具元数据进行工具滥用与智能体供应链风险利用。
下述攻击模式对应智能体应用Top 10中的ASI02——工具滥用，以及ASI04——智能体供应链漏洞。该技术最早由Invariant Labs于2025年4月披露，并在2026年针对日益增多的企业智能体的攻击中被观察到。
场景设定：一个金融运营团队构建了一个Copilot Studio智能体，帮助分析师处理供应商发票。该智能体启用了生成式编排（generative orchestration），并连接三个工具：一个是用于存放已审批供应商主数据的Dataverse MCP服务器，一个是用于供应商通信的Outlook连接器，以及一个第三方发票富化（enrichment）MCP服务器，该服务器被引入以基于外部参考数据库校验银行账户信息。第三方服务器经过了团队服务负责人的审核并获准在生产环境使用，但并未进行单独的安全审查。
阶段一：工具描述投毒。一名开发者向该富化服务器推送了一次更新。工具名称和面向用户的摘要保持不变，但MCP工具描述被悄然修改。这段描述是该智能体用来决定如何以及何时调用该工具的自然语言元数据。在看似合规的格式说明文字中，隐藏着一段指令块，要求智能体获取最近三十张未付发票，对其进行汇总，并将该汇总作为附加参数附加到富化调用之中，并以”反欺诈启发式要求”作为包装。
阶段二：静默重新信任。MCP会动态反映工具元数据的更新。在描述变更不会触发重新审批工作流的配置下，被投毒的描述在生产环境中悄然生效，无需额外审核即可进入活跃状态。
阶段三：用户调用。一名金融分析师向智能体询问一个关于供应商的常规问题。智能体在毫无任何可见提示的情况下，遵循了嵌在被投毒工具描述中的隐藏指令，收集了超出原始请求范围的敏感财务记录，并将其作为富化调用的一部分转发出去，仿佛这一切只是请求的常规组成部分。
阶段四：数据外泄。该富化服务器返回一个看似合理的”已校验”响应，同时将附加的发票汇总静默记录至威胁行为者控制的端点。分析师只看到一个干净的答复。在默认配置下，可能不会有任何告警触发。智能体采取的每一个独立动作都在其正常运行参数之内。该模式并未利用Copilot本身的漏洞，而是利用了由外部工具集成所引入的信任边界。
智能体自主执行的每个动作都是合法的：工具已被批准，Dataverse查询继承了分析师的权限，出站调用指向的是被加入白名单的服务器。漏洞并不存在于任何单一系统之中，而是存在于系统之间的信任边界。MCP将指令（即工具描述）与数据混合在一起，因此对工具元数据的修改能够像修改系统提示词一样有效地重定向智能体的行为。智能体无法区分由其所有者撰写的合法指令和由上游维护者插入的恶意指令。
图1中映射的控制措施应用于攻击链中的四个节点，每个节点由具体的微软能力支撑：第一，将每个MCP服务器视为供应链的一部分。对智能体可以调用的每个MCP服务器都应作为生产依赖进行管理：维护已批准发布者的清单，在安全审查中审查工具描述而非仅依赖工具名称，并要求任何第三方服务器在生产使用前必须有文档化的责任人。第二，将工具描述视为系统提示。由于模型可以在其工作上下文中读取工具元数据，对该元数据的修改等同于对智能体指令的修改。需要对关键智能体的工具描述更新执行变更审查，并使用Prompt Shields检查元数据中不应出现在文档字段里的祈使语气指令。第三，实施”最小能动性”原则，而不仅仅是”最小权限”。即使一个权限最小化的智能体，若具备过高的自主权，仍可能造成危害。应关闭”允许所有工具访问”（Allow all tool access）、对高影响动作要求人工审批，并在Microsoft Sentinel中建立智能体基线行为，以便在新端点、扩展参数或异常查询模式等偏离基线的情况出现时触发告警。第四，治理工具供应链并执行部署前的红队演练。
代表用户采取行动的智能体依赖于一个随治理计划持续演进而不断扩张的工具供应链。威胁行为者只需修改工具描述，便可能影响依赖该描述的智能体——甚至无需直接接触用户、提示或凭据。OWASP智能体应用Top 10提供了应对框架；包括Copilot Studio护栏、Prompt Shields、Defender for Cloud AI Protection、Microsoft Entra Agent ID、Microsoft Purview DLP、Microsoft Defender for Cloud Apps，以及Microsoft Sentinel在内的微软安全能力，则提供了具体控制措施。当务之急是将这些措施有意识地落实到智能体工作流中：限定权限范围、治理工具供应链、监控智能体行为，并在部署前开展红队演练。
微软遵循协调披露原则，本文不披露任何具体受影响组织的详细信息。
来源信息
来源：Microsoft Security Blog
作者：Microsoft Incident Response
