Hidden PR Comments Hijack AI Agents via Azure DevOps MCP

Key Takeaways

• Security researchers at Manifold Security disclosed an unpatched flaw in Microsoft’s official Azure DevOps Model Context Protocol (MCP) server that lets attackers hide instructions inside pull request descriptions using HTML comments, which are invisible in the web interface but returned in full to any AI agent that reads the PR through the API [1][2].
• The vulnerability is a confused-deputy attack: Microsoft’s repo_get_pull_request_by_id tool omits the “spotlighting” delimiters that wrap untrusted content elsewhere in the MCP server, so an AI reviewer cannot distinguish a legitimate PR description from an attacker’s embedded commands [1].
• In a proof-of-concept, a hidden instruction caused a victim’s agent to approve the malicious PR, trigger a pipeline in an unrelated “Payments” project, read a confidential wiki page, and post the contents back as a PR comment the attacker could retrieve — all using the victim’s own credentials [2].
• As of this writing, Microsoft has not assigned a CVE or shipped a fix. The company has characterized the issue as a known class of AI risk and has pointed to configuration-level mitigations; it has not committed to a code change [1][2].
• Organizations running AI code-review agents against Azure DevOps should restrict token scope, disable auto-approval workflows, and treat any AI-agent-authored approval or pipeline trigger as requiring independent verification until the underlying tool is fixed.

Background

Microsoft publishes an official Azure DevOps MCP server that lets AI coding agents read and act on Azure DevOps resources — pull requests, pipelines, wikis, and work items — using the authenticated user’s own permissions. This design mirrors a broader pattern across the MCP ecosystem, in which a server acts as a bridge between a large language model and a real enterprise system, translating natural-language requests into authenticated API calls. The convenience is significant: a developer can ask an agent to summarize a pull request, check pipeline status, or approve a routine change without leaving a chat interface. That convenience, however, assumes the content the agent reads while performing these tasks is trustworthy — an assumption this disclosure shows does not always hold.

Manifold Security’s disclosure, reported by The Hacker News and Cyber Security News in July 2026, undermines that assumption for one specific tool in the Azure DevOps MCP server [1][2]. The firm found that Microsoft had already implemented a defense called “spotlighting” for several tools that ingest external content, such as those reading wiki pages and build logs. Spotlighting wraps untrusted text in explicit delimiters so the underlying model can be instructed to treat the enclosed content as data to summarize, never as commands to execute. Manifold demonstrated that this protection was applied unevenly: the tool responsible for retrieving pull request descriptions, repo_get_pull_request_by_id, returns the raw text with no such wrapper, creating a gap in a control that is applied elsewhere in the same server [1].

This inconsistency matters because pull request descriptions are among the most routine content an AI code-review agent processes. Any developer or external contributor with write access to a repository can open a PR and write whatever they want in its description field, including standard Markdown formatting such as HTML comments. Those comments are a normal part of the Markdown specification, used by legitimate authors to leave notes that render invisibly on the page. The flaw Manifold identified repurposes that same invisibility: what a human reviewer never sees on screen is exactly what an AI agent receives when it calls the API to summarize the same PR.

Security Analysis

The attack chain begins with an adversary who already holds write access to at least one Azure DevOps project — a bar that external contributors, contract developers, or compromised low-privilege accounts can plausibly meet in many organizations. The attacker opens a pull request whose visible diff looks unremarkable, but whose description field contains an HTML comment such as <!-- ... --> carrying natural-language instructions directed at an AI agent rather than a human reader. Because Azure DevOps’s web rendering suppresses HTML comments, a human reviewer scanning the PR sees nothing out of the ordinary. The REST API that backs the MCP server, by contrast, returns the description field verbatim, hidden text and all [1][2].

The victim in this scenario is a developer or reviewer who has connected an AI coding agent to the Azure DevOps MCP server and asked it to review or summarize the pull request. Because the repo_get_pull_request_by_id tool does not apply spotlighting, the agent receives the hidden instructions with no signal that they originate from untrusted, attacker-controlled input rather than the operator’s own prompt. If the agent is configured to act on tool outputs without per-action confirmation — a configuration many teams choose specifically to streamline routine reviews — it will treat the embedded text as a legitimate next step.

Manifold’s proof-of-concept illustrates just how far this can reach. The injected comment instructed the victim’s agent to approve the pull request, then pivot to an entirely separate “Payments” project, trigger a pipeline there, read a confidential wiki page tied to that pipeline, and post the wiki contents back as a comment on the original PR, where the attacker — who had no direct access to the Payments project — could simply read it [2]. This is a confused-deputy attack: the agent, acting with the victim’s full authenticated privileges, performs actions the attacker could never have carried out directly, and hands the results to the attacker through a channel that looks like ordinary collaboration traffic. Successful exploitation depends on three conditions holding simultaneously: the attacker needs write access somewhere in the organization’s Azure DevOps environment, the victim needs broader access than the attacker across projects, and the victim’s agent needs to be configured to act on tool outputs with minimal human confirmation [1]. In practice, none of these conditions is unusual for organizations piloting AI-assisted code review, though the frequency of this specific combination has not been independently measured.

The technical root cause is narrower than the impact suggests — a single missing function call rather than a systemic design flaw. Microsoft’s own createExternalContentResponse helper function already exists specifically to prevent this class of attack, and it is already used for wiki and build-log tools. The pull request tool simply does not call it, delivering PR metadata to the model without the delimiters that would let the model reliably distinguish “content to describe” from “instructions to follow” [1]. The vulnerability report notes this has not yet resulted in a CVE assignment. Microsoft has characterized the issue as an instance of a known category of AI risk and has not committed to a code fix on a specific timeline. The vendor’s recommended mitigations to date — limiting project access and ensuring humans review changes before an agent acts on them — do not address the core problem, since the entire point of the attack is that the malicious content is invisible to the human reviewer performing that check [1][2].

Recommendations

Immediate Actions

Security and platform teams operating AI agents against Azure DevOps should audit which MCP tools their agents have access to and disable repo_get_pull_request_by_id or equivalent pull-request-reading tools until Microsoft ships a fix, if agent workflows can tolerate the loss of that capability. Where the tool cannot be disabled, teams should turn off auto-approval and auto-execution settings for any agent that consumes pull request content, requiring an explicit human confirmation step before the agent’s proposed action — approval, pipeline trigger, or comment post — actually executes. Teams should also retroactively scan recent and open pull requests for HTML comments or other content that renders invisibly in the Azure DevOps web interface, since an active campaign exploiting this flaw would leave exactly that kind of artifact behind.

Short-Term Mitigations

Organizations should scope the credentials or personal access tokens used by AI agents as narrowly as the workflow allows, limiting them to a single project rather than organization-wide access, so that even a successful injection cannot pivot across unrelated projects the way Manifold’s proof-of-concept did. Agent configurations should load only the MCP tool domains actually needed for a given task rather than the full Azure DevOps toolset by default, and should exclude higher-impact actions — PR approval, pipeline triggering, and wiki access — from the toolset available to any agent whose primary job is summarization or triage. Teams should also enable and review logging of agent tool-call traces, since an agent that approves a PR, triggers a pipeline, and posts a comment in immediate succession is an anomalous pattern worth alerting on regardless of the underlying vulnerability.

Strategic Considerations

This disclosure reinforces a pattern CSA’s own research has now documented across multiple MCP server implementations from different vendors (see below): inconsistent application of prompt-injection defenses within a single product recurs across cases rather than appearing as an isolated bug. Security teams evaluating any AI coding agent or MCP integration should require vendors to demonstrate that untrusted-content handling is applied uniformly across every tool that ingests external, user-controllable text, not merely in the tools a vendor considers highest-risk. Longer term, organizations should treat “AI agent acting with human credentials” as its own privilege tier requiring dedicated least-privilege architecture, separate from the identity and access model built for human users, since confused-deputy attacks like this one exploit exactly the gap between the two.

CSA Resource Alignment

This incident is a direct, real-world instance of the threat model CSA’s Confused Deputy Attacks on Autonomous AI Agents [3] formalizes: a privileged agent is tricked by a less-privileged, attacker-controlled input into misusing its own authority, executing injected instructions “using its full authority” because the underlying model cannot reliably distinguish operator commands from content it merely processes. The Azure DevOps case maps cleanly onto that paper’s four-stage chain — injection vector, authority inheritance, action propagation, and authority re-delegation — with the PR description as the injection vector and the pipeline-triggered wiki read as the re-delegation step.

The hidden-comment technique itself is close to identical to the mechanism CSA documented in Comment and Control: GitHub AI Agents as Credential Exfiltrators [4], which found that GitHub Copilot Agent could be hijacked by instructions hidden in HTML comment blocks that render invisibly to human reviewers but reach the model in raw form — the same construct Manifold demonstrated against Azure DevOps. Both cases also share an exfiltration pattern: the attacker retrieves stolen data through the same collaboration channel used to deliver the payload, whether a GitHub PR comment or an Azure DevOps PR comment, requiring no external infrastructure.

This disclosure additionally reinforces the pattern CSA’s Agentjacking: Sentry MCP Injection Hijacks AI Coding Agents [5] identified in a different MCP integration: an AI coding agent connected to a legitimate MCP server treats injected markdown or text returned by that server as authoritative guidance rather than untrusted data, a failure mode that recurred across Claude Code, Cursor, and OpenAI Codex CLI in that study with exploitation rates as high as 85 percent [5]. Organizations designing or auditing MCP-based agent deployments should also consult CSA’s AI Controls Matrix (AICM) v1.1 [6], particularly its Application and Interface Security and Identity and Access Management domains, when defining the least-privilege token scoping and tool-access controls recommended above.

References

[1] The Hacker News. “Microsoft Azure DevOps MCP Flaw Lets Hidden PR Comments Hijack AI Review Agents.” The Hacker News, July 2026.

[2] Cyber Security News. “Azure DevOps MCP Flaw Lets Hidden PR Comments Hijack AI Agents and Steal Data.” Cyber Security News, July 2026.

[3] Cloud Security Alliance. “Confused Deputy Attacks on Autonomous AI Agents.” Cloud Security Alliance, 2026.

[4] Cloud Security Alliance. “Comment and Control: GitHub AI Agents as Credential Exfiltrators.” Cloud Security Alliance, 2026.

[5] Cloud Security Alliance. “Agentjacking: Sentry MCP Injection Hijacks AI Coding Agents.” Cloud Security Alliance, June 2026.

[6] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” Cloud Security Alliance, 2026.