Does your team point a coding agent at Azure DevOps pull requests? You now have a configuration problem to fix. Researchers at Manifold Security disclosed an Azure DevOps MCP flaw this week. It lets an attacker hide instructions inside a pull request comment nobody can see. From there, the attacker can ride a reviewer’s own AI agent into projects they have no access to. Here is what the Azure DevOps MCP flaw actually does, and what to change before Microsoft ships a fix.
What makes the Azure DevOps MCP flaw exploitable
Azure DevOps PR descriptions render Markdown. Markdown supports HTML comments. A comment written as <!-- instructions here --> shows up as nothing at all in the web interface. A human reviewing the diff never sees it. But an AI agent can call Microsoft’s official Azure DevOps MCP server to fetch that same PR description. The server hands the comment text back word for word, hidden portion included.
One specific tool is at fault: the one that retrieves a pull request by id. It skips a protection Microsoft built for exactly this scenario. Other tools in the same server, covering wiki pages and build logs, wrap untrusted content in delimiters. That lets the agent’s model tell “this is data” from “this is an instruction.” The pull request tool never got that treatment. Anything hidden in a PR description reaches the model as plain, trusted-looking text.
An attacker only needs write access to one repository to plant the bait. Once a victim’s agent reviews it, that agent is still authenticated as the victim. It inherits the victim’s real permissions across the organisation, not just the one project the attacker touched. The technique has a name: prompt injection. Hide attacker text where a model reads it as a command instead of data, and it keeps turning up in AI coding tools well beyond this one server.
Check whether your setup is exposed
Three questions decide whether the Azure DevOps MCP flaw reaches your setup in practice.
Does your agent run in auto-approve mode? If it prompts a person before executing each tool call, the hidden instruction would surface at that confirmation step. Fully autonomous configurations, where the agent chains tool calls without asking, remove that check entirely.
Is the token scoped broadly? If the personal access token behind the agent covers an entire organisation rather than one project, that is a problem. A successful hijack can then reach pipelines, wikis and repositories well outside the PR the attacker actually touched.
Does the agent have tools it doesn’t need? A code-review assistant that can also trigger pipelines, read wikis and post comments carries three extra ways to cause damage. Each one is a fresh exfiltration path if the agent gets hijacked, on top of whatever the review task itself required.
What to change now
Scope tokens to a single project rather than an organisation-wide grant. A narrower token limits how far a hijacked agent can travel even if the injection succeeds.
Load only the MCP tool domains the task requires. The local Azure DevOps MCP server supports a flag to restrict which tool groups it exposes. A review-only agent does not need pipeline or wiki access at all. Removing those tools removes the exfiltration paths Manifold used in its proof of concept.
Put a human in the loop for anything that crosses project boundaries. Auto-approve is convenient. But it removes the one control this attack depends on you not having: a confirmation prompt before a cross-project pipeline run or a wiki read.
Log what your agents actually do. A review agent that suddenly triggers a build in an unrelated project is a signal worth alerting on. So is one that posts a comment full of data it was never asked to fetch. Manifold’s proof of concept worked against both GitHub Copilot CLI and Claude Code. So this is not a single-vendor quirk to patch around; it is a pattern to monitor for, regardless of which agent your team uses.
Why the usual advice falls short here
Microsoft’s standard guidance, limit access and review changes before running AI tools on them, assumes a human reviewer would notice something off. That assumption breaks the moment the payload is an HTML comment that renders as nothing. Reviewing the visible diff tells you nothing about what an agent will read once it calls the API directly.
Manifold reported the issue to the Microsoft Security Response Center, which has acknowledged and triaged it. No CVE has been assigned and no patch has shipped as of publication. Microsoft has not yet applied its own spotlighting guardrail to the pull request tool, the same way it already has for wikis and build logs. Until it does, the mitigations above are the only real defence against this Azure DevOps MCP flaw.
The underlying lesson travels well beyond Azure DevOps. Any MCP server that feeds an agent content written by someone else, a ticket, a support message, a code comment, is exposed the same way. That content needs to be wrapped and labelled before the model ever sees it. Test your own MCP integrations for the same gap. Pick a tool that returns user-authored text, and check whether it is wrapped the same way as the tools your vendor tested first.