Microsoft Azure DevOps MCP Flaw Lets Hidden PR Comments Hijack AI Review Agents
A single invisible comment in an Azure DevOps pull request can turn a reviewer’s own AI coding agent against them, driving it into projects the attacker has no rights to reach and quietly leaking what it finds.
The flaw is in Microsoft’s official Azure DevOps MCP server, and it works because one of its tools returns pull request descriptions without a prompt-injection guardrail the company had already applied to others.
Offensive security firm Manifold Security detailed the confused-deputy bug this week. Microsoft ships the server so AI agents can read and operate Azure DevOps for a user, across pull requests, pipelines, wikis, and work items, all with the user’s own permissions. That is the whole problem: content other people wrote can become instructions the agent acts on.
Azure DevOps PR descriptions accept Markdown, which allows HTML comments. In the web UI, an HTML comment (<!– … –>) renders as nothing, so a reviewer scrolling the description sees an ordinary change. The REST API returns it verbatim, and the server hands that text straight to the agent.
That split between what the human sees and what the model receives is the delivery mechanism: the attacker never talks to the agent but plants instructions in content they know it will later read.
When the reviewer asks their agent to review the PR, the hidden text can rewrite the agent’s goal. The agent is carrying the reviewer’s credentials, so it can act across projects the attacker has no rights to reach.
Manifold says that access reaches source code, secrets, and work items, not just the wiki page its proof of concept exfiltrated. The firm calls the escalation the normal case, since reviewers are often more senior than whoever opened the pull request. The attacker gains nothing directly; they borrow the reviewer’s access through text the reviewer never sees.
The pull request path missed the guardrail
What lifts this above a generic prompt-injection warning is that Microsoft already shipped a defense for it. Reading the server’s source, Manifold found it uses spotlighting, a technique from Microsoft’s own guidance on indirect prompt injection: it wraps untrusted content in delimiters so the model can tell data apart from the instructions it should follow.
The company added it in PR #1062, where the wiki-page and build-log tools pass their output through a shared helper, createExternalContentResponse. The tool that returns a pull request, repo_get_pull_request_by_id, never calls it, so it hands back the description raw, which is exactly the surface an attacker writes to.
The Hacker News confirmed the same path is still uncovered in the current source as of July 21.
In Manifold’s proof of concept, run on a local build of v2.7.0, a contributor to one project opens a normal-looking PR whose hidden comment carries the payload. Once the agent starts its review, the tool trace runs a chain: it triggers a pipeline in a different project, reads a confidential wiki page the attacker cannot open, and posts that page back as a comment on the PR, where the attacker reads it.
A single hidden comment drove the whole sequence, and every call in it was one the agent was allowed to make. The problem, the researchers wrote, was “the sequence and intent, driven by text that a human never saw.” The team reproduced it with both Copilot CLI and Claude Code, so it is not tied to one agent.
The chain has prerequisites, though: attacker-written PR text, a workflow that feeds it to an agent, a reviewer whose access exceeds the attacker’s, and an agent cleared to run tools without asking.
Manifold confirmed it tested that last part as an auto-approve posture with no per-tool prompts, the checkpoint that would otherwise let a reviewer catch an odd cross-project pipeline run before it fires. A broad token plus that posture is where the risk concentrates.
The demo assumes a person kicks off the review, but Manifold notes where teams are heading: automated review, triage, and summaries fired by triggers, with no human prompting each run or reading each result. In that setup, the planted description fires on its own, and the leak runs longer before anyone notices.
The pattern is not new. In May 2025, Invariant Labs showed the same class of attack against GitHub’s MCP server, using a public issue to push an agent into reading a private repo and leaking it through a pull request; the same technique has since reached automated GitHub agent workflows.
That case was one of the examples Simon Willison pointed to in naming the lethal trifecta: an agent with access to private data, exposure to untrusted content, and a way to send data out. Any agent with all three can be turned on its owner by one piece of text, and most useful ones have all three.
A Microsoft spokesperson thanked Manifold for reporting the behavior under coordinated disclosure and called it “a known class of AI risk” that informs the company’s ongoing work on its safeguards. Microsoft did not say whether it would change the code or assign a CVE.
It noted the attack requires an attacker to already have write access to a project and a second user to invoke an AI tool over the content, and recommended customers limit project access and “review proposed changes before asking an AI tool to act on them.” The catch is that the payload here is invisible in the interface a human reviews.
As of July 21, there is no fixed release, and The Hacker News found no CVE assigned to the flaw in public databases. The latest release, v2.8.0, shipped on June 24. No public report places the technique in use outside Manifold’s own testing.
Manifold tested only the local, PAT-based server, but told The Hacker News the root cause is “in the server’s code, not the transport.” By that logic, the hosted remote MCP server would be exposed too, but Manifold did not test it, and Microsoft did not address it.
Spotlighting raises the bar but does not close prompt injection by itself, so the defenses are the familiar ones. Give the agent least-privilege tokens and scope it to the project under review. Load only the MCP domains the task needs; the local server narrows them with a -d flag.
Keep pipeline runs, wiki reads, and comment posting out of a code-review tool set that has no use for them. To check whether the chain has already run, look in the agent’s tool traces for cross-project pipeline runs, wiki reads, or comments it posted during a review, and scan open PR descriptions for hidden HTML comments. A human reviewer who cannot see the payload is not a control.
The guardrail only works where someone remembers to add it. It wraps untrusted content one response path at a time, so the defense is only as strong as its least-covered path, and a missing wrapper on a single function is close to invisible from outside. On a tool surface that keeps growing, gaps like this open faster than anyone thinks to audit them.
About Author
