Hidden PR Text Can Hijack Azure DevOps AI Reviews

How the attack worked

Researchers demonstrated that Azure DevOps pull request descriptions accept Markdown, which allows HTML comments. In the web UI, an HTML comment renders as nothing, so a reviewer scanning a PR sees a normal description. But the Azure DevOps MCP server tool path for pull requests returns the full PR description text, including the hidden comment, to any AI agent that reads it. When a reviewer asks their agent to review the PR, the hidden instructions can rewrite the agent's goal without the reviewer ever noticing.

In the proof of concept, the agent's tool trace showed a chain of actions well beyond reviewing code: it triggered a pipeline in a different project, read a confidential wiki page the attacker could not open directly, and posted that page's contents back as a comment on the PR, where the attacker could read it.

Why it succeeded

The core issue is that the AI agent acts with the reviewer's own permissions. Since the agent is carrying the reviewer's credentials, it can reach projects and data the attacker has no rights to access on their own. The gap between what a human sees in the interface and what the model actually receives as input is the delivery mechanism for this attack. The risk grows when agents are configured to run tools automatically without per-tool confirmation, and when review workflows are triggered automatically rather than manually.

What to watch for

• Pull request descriptions containing HTML comments that are invisible in the rendered UI
• AI agent tool traces showing unusual cross-project actions during what should be a simple code review, such as pipeline runs or wiki reads
• PR comments posted by an agent that contain internal or confidential information unrelated to the actual code change
• Agents configured to auto-approve tool actions with no per-tool confirmation prompts

How to build resistance

Organizations using AI coding agents connected to internal tools like Azure DevOps should treat pull request text as untrusted input, since hidden content can exist even when the interface looks clean. Practical steps include requiring explicit human approval before an agent runs sensitive actions such as triggering pipelines or accessing wikis, giving agents least-privilege tokens scoped only to the project under review rather than broad cross-project access, and regularly auditing agent tool traces for cross-project pipeline runs, wiki reads, or comments posted during reviews. These measures reduce the chance that a hidden instruction in a PR can turn a routine review into a path for data exfiltration.

How can hidden text in a pull request affect an AI code reviewer?

An attacker can insert an HTML comment into a PR description that renders as nothing in the web UI but is still returned to the AI agent through the API, letting the hidden text redirect the agent's actions during review.

What kind of damage can this prompt injection cause?

In a proof of concept, the agent used the reviewer's own permissions to trigger a pipeline in another project, read a confidential wiki page, and post that page's contents back into the PR comment thread where the attacker could see it.

Why does this attack work even though the reviewer never sees the hidden instructions?

The AI agent reads the full PR description text via the API while the human reviewer only sees the rendered version in the UI, so the gap between what a human sees and what the model receives becomes the delivery mechanism.

How can teams reduce this risk?

Require explicit approval for sensitive agent actions like pipeline runs or wiki access, scope agent tokens to least privilege for the project under review, and audit tool traces for unexpected cross-project activity.