Azure DevOps MCP漏洞 隐藏评论劫持AI审查

一、漏洞背景：AI代码审查成攻击新入口

随着AI辅助编程与智能代码审查普及，AI智能体被赋予更多企业级权限。微软为Azure DevOps推出的官方MCP服务器（azure-devops-mcp），正是让智能体以用户身份操作拉取请求、流水线、Wiki与工作项的桥梁，用户可通过本地或远程方式接入Copilot CLI、Claude Code等工具。MCP（模型上下文协议）是连接大模型与外部工具、数据的开放标准，正成为AI应用的通用接口。本周，安全公司Manifold Security披露了该服务器的一处"混淆代理"（confused deputy）漏洞：攻击者只需在PR描述中写入一条人眼不可见的注释，就能劫持审查者的AI智能体，越权访问其无权接触的项目，外泄源代码、密钥与工作项数据。The Hacker News核实，截至7月21日该缺陷仍未修复。

二、攻击原理：人看不见，模型却照单全收

漏洞的根源在于PR描述同时支持Markdown与HTML注释。在Azure DevOps网页界面中，HTML注释（形如）默认不渲染任何内容，审查者看到的只是一次普通变更；但REST API会原样返回这段文本，MCP服务器随后把它直接交给AI智能体——"人看到的内容"与"模型接收的内容"就此分道扬镳，这正是攻击的投递机制：攻击者从不直接与智能体对话，而是把指令埋进它必然读取的内容里。更值得注意的是，微软其实已有防护：其官方指南建议对间接提示注入使用"聚光"（spotlighting）技术，用分隔符包裹不可信内容，区分"数据"与"指令"。服务器在PR #1062中已为wiki页面、构建日志等工具接入统一的辅助函数，唯独返回PR详情的repo_get_pull_request_by_id工具漏掉了这一层，原样交出描述文本。

Manifold基于v2.7.0本地构建复现了完整攻击链：攻击者在某项目打开一个看似正常的PR，隐藏注释携带载荷；审查者让智能体审查该PR后，恶意文本重写其任务目标——智能体触发另一项目的流水线，读取攻击者无权访问的机密wiki页面，再将内容作为评论发回PR供攻击者查看。链上每个调用都是智能体被允许执行的，问题出在"由人类从未看过的文本驱动的意图与顺序"。该攻击在Copilot CLI与Claude Code上均可复现。

三、影响与防护：最小权限才是硬道理

这并非孤例。2025年5月，Invariant Labs曾对GitHub官方MCP服务器展示同类攻击，利用公开issue诱导智能体读取私有仓库并借PR外泄；如今同一手法已蔓延至自动化GitHub Agent工作流。这类攻击对应Simon Willison提出的"致命三要素"：智能体可访问私有数据、暴露于不可信内容、具备数据外发通道——多数实用型智能体恰好三者兼具，因此一条文本就能让其"反噬"主人。就本次案例而言，攻击成立需要几个前提：攻击者拥有项目写权限、存在把PR文本喂给智能体的工作流、审查者权限高于攻击者、智能体以自动批准模式运行。Manifold正是在该姿态下完成验证，宽泛令牌叠加自动批准正是风险集中点。

微软回应称这是"已知类别的AI风险"，按协调披露流程致谢，但未承诺修复，也未分配CVE编号；最新版本v2.8.0（6月24日发布）未覆盖该路径。Manifold仅测试了基于PAT的本地服务器，但认为根因在服务器代码而非传输层，远程托管版大概率同样受影响。防御层面，InfoQ近期一篇关于MCP生产环境纵深防御的文章提出四层控制：安全执行、管理基础设施、出站信任与语义完整性，强调防护不能只依赖网关，而要在最早的可信控制点落地。实操层面：为智能体签发最小权限令牌并限定项目范围；按需加载MCP域，本地服务器可用-d参数裁剪；移除流水线触发、wiki读取、评论发布等审查用不到的能力；定期检查智能体工具追踪日志，留意跨项目流水线、wiki读取或审查期间发布的评论，并扫描PR描述中的隐藏HTML注释。务必牢记：看不见载荷的人类审查者，本身不构成有效防线。

四、对青海政企的启示

对青海的启示同样直接。目前省内政务云、医疗、教育等领域政企单位正陆续试点AI辅助编码与智能代码审查，把大模型接入内部代码托管平台，MCP等连接协议也随之进入生产环境。结合本次事件，建议青海政企在引入AI开发工具时做到四点：一是把MCP服务器、AI智能体纳入上线前安全评估，核查其工具权限清单；二是坚持最小权限原则，禁止为智能体配置宽泛令牌，代码平台落实项目级权限隔离，避免"审查者权限"成为被借用的越权通道；三是建立AI工具行为审计，定期核查调用日志，及时发现跨项目异常操作；四是结合等保2.0要求，将AI辅助开发纳入年度安全检查与人员培训，让安全能力与AI提效同步升级。