Azure DevOps MCP Flaw Lets Hidden PR Comments Hijack AI Agents — What Teams Need to Know

Azure DevOps MCP Flaw Lets Hidden PR Comments Hijack AI Agents

On July 21, 2026, Manifold Security disclosed a confused-deputy vulnerability in Microsoft’s official Azure DevOps Model Context Protocol (MCP) server. The flaw allows an attacker with write access to a single Azure DevOps project to hijack a reviewer’s AI coding agent — using invisible text in a pull request description — and steal data from projects the attacker cannot otherwise access.

Microsoft acknowledged the finding and is investigating, but as of July 22, no fix or CVE has been released. The latest release (v2.8.0, June 24) does not address it.

How the Attack Works

The vulnerability combines three elements to turn an AI assistant against its user:

1. Delivery via HTML comment. Azure DevOps PR descriptions support Markdown, including HTML comments (<!-- ... -->). An attacker opens a normal-looking PR but hides malicious instructions inside a comment block. In the Azure DevOps web UI, the comment renders as nothing — the reviewer sees a clean, innocuous description. But the REST API returns the comment verbatim, and the MCP server’s repo_get_pull_request_by_id tool hands it directly to the agent’s context.

2. Goal hijacking. The reviewer asks their AI coding agent to review the PR, the hidden instructions rewrite the agent’s objective mid-task. For example, the injected text can instruct the agent to trigger a pipeline in a different project, read a confidential wiki page, and post its contents back as a comment on the attacker’s PR.

3. Credential escalation. The agent operates with the reviewer’s credentials, letting the attacker borrow privileged access without ever touching the target project directly. Manifold Security validated the attack with both GitHub Copilot CLI and Claude Code, confirming the flaw lives in the MCP server code, not in any single agent.

The Spotlighting Gap

Microsoft had already built a defense for this class of attack. In PR #1062 (merged March 30, 2026), the team introduced “spotlighting” — cryptographically-secure, nonce-based delimiters that wrap untrusted external content so the LLM can distinguish data from instructions. The implementation uses 128-bit cryptographic random nonces and was applied to wiki_get_page_content and pipelines_get_build_log_by_id.

The problem: repo_get_pull_request_by_id never received the spotlighting treatment. This is the exact tool that returns PR descriptions — the one surface an attacker controls directly. The tool still returns raw, unsanitized text to the LLM context, making the entire guardrail bypassable for the most critical entry point.

Why This Matters: The Lethal Trifecta

Security researcher Simon Willison’s “lethal trifecta” framework explains why this attack is so hard to defend against with detection alone:

1. Access to private data — the agent holds the victim’s credentials
2. Exposure to untrusted content — the agent reads attacker-written PR descriptions
3. A way to send data out — the agent can post PR comments the attacker reads

Any AI agent with all three capabilities can be turned against its owner by a single piece of text. Most genuinely useful coding agents have all three.

Broader Impact

The attack surface extends beyond manual reviews. As teams adopt automated PR review workflows — triage bots, summary generators, triggered analysis — a planted description fires autonomously. The more automated the pipeline, the wider the blast radius and the longer the exfiltration goes unnoticed.

Palo Alto Networks’ Unit 42 cataloged HTML comments as an established Indirect Prompt Injection (IDPI) delivery technique in a March 2026 report, identifying 22 distinct injection methods observed in the wild. This attack follows a well-documented pattern.

The vulnerability also has historical precedent. Invariant Labs demonstrated an identical issue against the GitHub MCP server in May 2025 — a pattern that now repeats with Azure DevOps.

Microsoft’s Response

A Microsoft spokesperson:

• Thanked Manifold Security for coordinated disclosure
• Characterized the issue as “a known class of AI risk” that informs ongoing safeguard work
• Did not commit to specific code changes or a CVE assignment
• Recommended limiting project access and “review[ing] proposed changes before asking an AI tool to act on them” — though the payload remains invisible in the UI

Practical Mitigations

Until a patch is released, organizations using Azure DevOps MCP can reduce exposure:

1. Least-privilege tokens — scope the agent’s token to the project under review, not the full organization. A token limited to a single project cannot be used for cross-project data access.

2. Narrow MCP tool scope — load only the tools the task needs. Exclude pipelines_run_pipeline and wiki_get_wiki_page_content from a code-review toolset using the -d flag in the local MCP server.

3. Per-tool approval prompts — require human confirmation before cross-project pipeline runs or wiki reads, adding an approval gate that automated injections cannot bypass.

4. Scan open PRs — check existing PR descriptions for hidden HTML comments that may already contain injection payloads.

5. Audit agent traces — monitor for unexpected cross-project pipeline runs, wiki reads, or PR comment posts during review sessions.

The observability and monitoring practices covered in Observability for AI Agents: What to Log, Trace, and Alert On provide a practical starting point for detecting anomalous agent behavior.

What This Means for AI Agent Deployments

This disclosure reinforces a pattern we are seeing repeatedly in 2026: MCP servers, connectors, and plugins — the middleware between AI agents and enterprise tools — are emerging as a critical and under-hardened attack surface.

The reality is that prompt injection cannot be fully prevented through agent behavior alone when the server returns untrusted content in the same channel as trusted instructions. The Microsoft spotlighting approach is a sound technical defense — but it is only effective when applied consistently to every content-returning tool. A single gap, as this vulnerability demonstrates, can be exploited.

For a deeper look at prompt injection defense strategies, the Securing AI Agents Against Prompt Injection — IBM Technology post covers production-tested defense-in-depth approaches that apply to this class of attack.

Current Status

Detail	Value
Disclosed by	Manifold Security
Disclosure date	July 21, 2026
CVE	None assigned (as of July 22)
Fix released	No (v2.8.0 latest, June 24)
Attack vector	HTML comment in PR description
Root cause	repo_get_pull_request_by_id missing spotlighting
Guardrail PR	#1062 — only applied to wiki and pipeline tools
Tested agents	GitHub Copilot CLI, Claude Code

The disclosure is a useful reminder that as AI coding agents become standard in engineering workflows, the security of the infrastructure connecting them to developer tools deserves the same scrutiny we apply to APIs and authentication systems. A single unguarded endpoint can turn a productivity tool into a data exfiltration channel.