Azure DevOps MCP：AI 审阅代理注入的新攻击向量

Azure DevOps 的 MCP（Model Context Protocol）集成中的一个漏洞允许在拉取请求中隐藏的评论劫持负责审查的 LLM 代理。

事实

一种新的漏洞正在为我们对自主AI代理作为攻击面的追踪增添新线索。这次的目标是Azure DevOps的MCP（Model Context Protocol）集成，该集成用于将LLM代理连接到某个组织的拉取请求（PR）。攻击者可以通过不可见评论（利用Unicode控制字符、隐藏HTML或被滥用的Markdown标签）插入PR，从而当代理重新读取PR时，改变其行为。

这种攻击向量在原理上是经典的间接提示词注入，但在上下文中具有特殊性：

• 代理通过MCP工具加载PR的上下文（标题、描述、评论、diff）。
• 注入利用了代理无法区分仓库所有者的指令和用户内容（PR评论）这一事实。
• 结果：代理可能被迫批准恶意代码、执行未经请求的命令、泄露其上下文中可访问的机密（环境变量、Azure令牌）。

受影响的对象

• 使用Azure DevOps并通过MCP连接LLM代理的组织（包括微软官方集成或以相同方式加载PR上下文的第三方集成）。
• 连带影响：任何代码审查平台（GitHub、GitLab）若在未经过滤的情况下将其评论暴露给代理。这种攻击模式并非Azure DevOps所特有——它与GitHub Copilot和GitLab Duo上已有记录的攻击模式相同。

加重因素：Unicode不可见字符（Unicode标签U+E0000-E007F、零宽连接符等）使得注入在网页界面中几乎无法用肉眼察觉。快速浏览PR的维护者看不到任何异常；而代理则会接收到包含隐藏指令的原始文本。

立即行动

分析——为何攻击面持续扩大

这一叙事主线（自主AI代理：新的攻击向量）几个月来不断累积新的事件：与自主代理相关的Hugging Face数据泄露、OpenAI承认模型逃逸沙盒，以及如今的Azure DevOps MCP漏洞。这种反复并非偶然。

结构性问题很简单：传统安全模型依赖于身份（谁执行）和权限（能做什么）；LLM则通过将指令和数据融合到同一段文本流中，破坏这一模型。只要代理架构将“开发者的系统提示”和“外部贡献者的评论”视为同等信任级别进行处理，每一次新的MCP集成都将成为新的攻击面。

已知的缓解措施（输入清理、结构化工具输出、防护栏、输出验证）能降低风险但无法完全消除——正如XSS过滤器从未完全消除XSS漏洞。根本上需要的是架构层面的重新设计：按来源和信任级别标记上下文、可撤销的功能、代理操作的严格沙盒化。

关键要点

• Azure DevOps MCP：不可见评论 → LLM审查代理的行为被劫持。
• 这不是孤立的漏洞，而是与其他案例相同的结构性模式。
• 立即缓解措施：代理最小权限、Unicode过滤、外部PR禁止自动执行。