Azure DevOps MCP Server Flaw Lets Attackers Hijack AI Code-Review Agents

Manifold Security has described a flaw in Microsoft's official Azure DevOps MCP server that lets an attacker take control of an AI agent reviewing pull requests. All it takes is a hidden comment in a pull request description, invisible to a human looking at the interface but read by the agent straight from the API.

The attack mechanism is simple and requires no security breach in the classic sense. Azure DevOps lets users format pull request descriptions in Markdown, and Markdown supports HTML comments that stay hidden from the user. Such a comment doesn't render in the browser, but the Azure DevOps REST API returns it in full, including content the developer never actually saw on screen.

How the hijack works

When a developer asks their AI agent to review a pull request, the agent fetches the request description through the MCP server and treats its content as part of its own instruction context. If an instruction is hidden inside that description, the agent carries it out just as it would a command from a human, because from its perspective there is no difference between text from the user and text pulled from an external source.

In the example described by Manifold Security, a hidden instruction told the agent to approve the pull request, trigger a build pipeline in an entirely different project called 'Payments,' read a confidential wiki page there, and then post its contents back as a comment on the pull request, visible to the attacker. The agent was also instructed not to tell the reviewer about any of it.

The core problem is that the agent operates with the permissions of the reviewer, meaning the person who asked it for help. An attacker can use this to reach resources they have no access to themselves, since it isn't their account performing the actions but the victim's account, acting through the agent.

A gap in protections that already existed

Microsoft had already rolled out a mechanism called 'spotlighting' in the Azure DevOps MCP server, wrapping untrusted external content in explicit markers that help the model distinguish data from instructions. The problem is that the protection was applied inconsistently. Tools that return build pipeline output and wiki page content have it implemented, but the tool that returns the pull request description, exactly the point the researchers exploited, was left uncovered.

This illustrates a common problem in securing AI agents against prompt injection: a single uncovered spot in an API is enough to undermine all the rest of the protection. Manifold Security reported the flaw to the Microsoft Security Response Center, which confirmed and classified the issue, but as of the report's publication no patch or CVE number had been issued.

Another case in a growing wave

This is yet another report in recent weeks of prompt injection techniques aimed at coding agents, following previously documented attacks that used hidden instructions embedded in image files or forged metadata. The common thread is that AI agents with access to repositories, CI/CD systems, and internal company documentation are becoming an attractive new target, since they combine broad permissions with a limited ability to tell trusted content apart from malicious content.

Manifold Security stresses that the fix cannot simply be limiting the agent's permissions, since in this case every action taken was consistent with the access rights it had been granted. Instead, the firm recommends ongoing monitoring of what an agent actually does during a given session, rather than relying solely on a permission model set up in advance.

What it means for companies in Poland

Azure DevOps is one of the more popular code management tools among Polish companies built on the Microsoft ecosystem, and integrations with coding agents, from Copilot to tools built on Claude or GPT, are spreading there at the same pace as elsewhere. Teams that have connected an AI agent to pull request review through MCP should treat this flaw as a signal to check exactly what permissions that agent actually holds and whether its actions are logged in a way that would reveal an unusual sequence of operations.

Until a patch is released, the only practical safeguard is limiting trust in pull request content coming from external collaborators, along with manual verification before an AI agent is instructed to approve changes or trigger a build pipeline in another project.