Invisible PR Comments Hijack AI Code Review Agents

Key Takeaways

Security researchers at Manifold Security disclosed a confused-deputy vulnerability in Microsoft’s official Azure DevOps Model Context Protocol (MCP) server that lets an attacker hide instructions inside a pull request description using HTML comments invisible in the Azure DevOps web interface but returned verbatim by the REST API [1][2]. When a developer asks an AI coding agent such as GitHub Copilot CLI or Claude Code to review the pull request, the agent reads the hidden text and executes it as if it were a legitimate instruction from the reviewer, carrying out actions such as approving the change, triggering pipelines in unrelated projects, retrieving confidential wiki pages, and posting the results back as a PR comment the attacker can read [1][2]. The vulnerability stems from inconsistent application of a defense Microsoft calls “spotlighting,” which wraps untrusted content in delimiters so a model can distinguish data from instructions; Microsoft applied spotlighting to the server’s pipeline and wiki tools but not to the tool that returns pull request descriptions, the exact entry point the attack exploits [2]. As of the researchers’ July 31, 2026 disclosure, Microsoft’s Security Response Center had acknowledged and triaged the report, but no CVE had been assigned and no patched release was available, leaving organizations that have deployed the Azure DevOps MCP server to rely on configuration-level mitigations in the interim [1][2].

Background

Microsoft’s Azure DevOps MCP server is the company’s official bridge between Azure DevOps — the platform teams use for source control, work item tracking, pipelines, and wikis — and AI coding agents that speak the Model Context Protocol. It exposes a catalog of tools that let an agent read pull requests, inspect pipeline runs, browse wiki content, and post comments, all under the credentials of whichever developer has authorized the connection [1]. That design is what makes the server useful: a developer can ask an agent to summarize a pull request, check whether a pipeline succeeded, or pull context from a project wiki without leaving their coding session. It is also what makes the server dangerous when a tool call returns content an attacker controls, because the agent has no independent way to tell where a piece of text came from once it lands in the model’s context window, absent an explicit defense such as the delimiter-based “spotlighting” technique discussed below.

Azure DevOps pull request descriptions accept Markdown, and Markdown permits raw HTML comments that render as nothing at all in the web interface — a reviewer scrolling through the description in a browser sees an ordinary, unremarkable change summary [1][2]. The repo_get_pull_request_by_id tool, however, returns the description exactly as submitted, hidden comment included, and hands that text directly to whichever agent invoked it [1][2]. Manifold Security’s proof of concept opened a pull request in a project the attacker had contributor access to, embedded an HTML comment instructing an AI reviewer to approve the change, trigger a pipeline in a second project the attacker could not reach directly, retrieve a confidential wiki page from that project, and post the wiki contents back as a comment on the original pull request — all while telling the agent not to mention any of this to the human reviewer [2]. Because the agent acts with the reviewer’s own Azure DevOps credentials rather than the attacker’s, it can complete every step even though the attacker never had permission to touch the second project, satisfying the classic definition of a confused-deputy attack: a privileged actor tricked into using its own authority on an adversary’s behalf [2].

Manifold Security reported the finding to Microsoft through the Microsoft Security Response Center, which acknowledged and triaged the report [2]. A Microsoft spokesperson characterized the issue as “a known class of AI risk” and pointed customers toward limiting project access and reviewing changes before invoking AI tools, guidance that does not address the core mechanism of the attack: the hidden payload is, by design, invisible to a human scanning the pull request in the normal interface [1]. The researchers tested the flaw against a local build of version 2.7.0 — Microsoft’s latest release, v2.8.0, had shipped June 24, 2026 without addressing the flaw — and confirmed exploitation against both GitHub Copilot CLI and Claude Code operating as the reviewing agent, indicating the vulnerability sits in the MCP server’s tool implementation rather than in any particular client [1][2]. Publication followed on July 31, 2026, with no CVE identifier assigned and no fixed release available at that time, a timeline corroborated by subsequent security-press coverage of the disclosure [1][2][3].

Security Analysis

The technical gap is narrow but consequential: Microsoft built spotlighting into some of the Azure DevOps MCP server’s tools and not others, and the coverage decision that mattered most — protecting the tool most likely to carry attacker-supplied text before a human has reviewed it — left the highest-risk tool unprotected. Table 1 summarizes which tool categories in the server carry the spotlighting defense as of the disclosure and which the researchers found exploitable.

The asymmetry matters because pull request descriptions are, by design, the one artifact in this workflow that routinely contains text written by someone other than the person invoking the agent. A developer reviewing a colleague’s pipeline configuration or an internal wiki page is typically consuming content their own organization produced; a developer reviewing a pull request is, by the nature of code review, consuming content from whoever opened it — potentially an external contributor, a compromised internal account, or, in organizations with open contribution models, any of a potentially large and unvetted pool of contributors. Leaving the highest-risk ingestion point unprotected while hardening lower-risk ones is consistent with a spotlighting rollout applied tool-by-tool rather than driven by a systematic assessment of which data sources are most likely to carry adversarial content, though Microsoft has not described its internal process for sequencing the defense; either way, the gap is easy to reproduce in any MCP integration built incrementally over time.

The confused-deputy mechanics compound the injection problem rather than merely following from it. Because the agent operates with the reviewing developer’s own Azure DevOps token, the attacker’s payload inherits whatever access that developer has been granted — potentially spanning every project in the organization, not just the one where the malicious pull request lives. This is precisely the access-amplification pattern that makes indirect prompt injection against agentic tools qualitatively worse than against a standalone chatbot: a chatbot that is tricked into saying something false produces a false statement, while an agent that is tricked into calling a tool produces a real action taken with real credentials. The proof of concept’s specific chain — cross-project pipeline execution, confidential wiki exfiltration, and covert comment-based exfiltration — demonstrates that the blast radius of a single unreviewed pull request comment can extend well beyond the repository it was posted in, reaching, in principle, any resource the reviewing developer’s token can touch, not merely the project where the malicious PR was opened.

It is also worth noting what the vulnerability does not require. The attacker needs no elevated Azure DevOps role, no prior foothold on the victim’s workstation, and no exploitation of the MCP protocol itself; ordinary contributor-level access to open a pull request is sufficient. That low bar, combined with the payload’s invisibility to manual PR review — likely still the primary human control at most organizations — means detection depends on monitoring what the agent actually does rather than on catching the malicious text before it is processed. An agent that unexpectedly triggers a pipeline in a project unrelated to the one under review, or that retrieves a wiki page it was never asked to fetch, is a more actionable detection signal than attempting to sanitize pull request text after the fact, since Markdown’s legitimate support for HTML comments means the hiding technique itself is not inherently malicious and cannot simply be blocked outright without breaking normal PR authoring.

Recommendations

Immediate Actions

Organizations running the Azure DevOps MCP server should scope the personal access tokens or OAuth grants used by AI review agents to the single project under review rather than issuing organization-wide access, which directly limits how far a hijacked review session can reach even if the injection succeeds [2]. Teams should also configure their MCP client to load only the tool domains a code-review task actually needs, removing pipeline execution, wiki retrieval, and comment-posting capabilities from any agent whose job is limited to reviewing pull request content, since none of those capabilities are necessary for the review itself and each is a step in the disclosed attack chain [2]. Until Microsoft ships a fix, security teams should treat any AI agent connected to this MCP server as capable of acting on hidden instructions embedded in any pull request it processes, and should audit recent AI-assisted reviews for pipeline runs or wiki accesses that do not correspond to a task the human reviewer actually requested.

Short-Term Mitigations

Security and platform engineering teams should require human approval for any agent action that crosses project boundaries — approving a pull request in the project under review is a fundamentally different risk than triggering a pipeline or reading a wiki page in a different project, and gating the latter behind explicit confirmation closes most of the proof of concept’s exfiltration path even before Microsoft patches the underlying tool [2][4]. Organizations should also instrument logging that captures what MCP tools an agent invokes during a review session, distinct from ordinary Azure DevOps audit logs, so that a review agent’s tool calls can be compared against the scope of the task a developer actually assigned it; an agent that reads a wiki page or runs a pipeline without having been asked to do either is a meaningful indicator worth investigating, regardless of whether the underlying content that triggered it can be inspected directly. Where feasible, teams should apply the same scrutiny to any other MCP server integration handling externally authored content — issue trackers, code review comments on other platforms, or ticketing systems — since the pattern of an unprotected tool sitting alongside protected ones is unlikely to be unique to this single Microsoft product.

Strategic Considerations

This disclosure reinforces that partial mitigation coverage across an MCP server’s tool catalog is itself a security-relevant configuration, not merely an implementation detail, and organizations evaluating any MCP integration — whether built in-house or supplied by a vendor — should ask specifically which tools carry prompt-injection defenses and which do not, rather than assuming a vendor’s general commitment to AI safety extends uniformly across every tool it ships. Because the underlying weakness is architectural rather than a simple coding bug, and because Microsoft’s own comment framed this as “a known class of AI risk” rather than a one-off defect, enterprises should expect comparable gaps to surface in other AI-integrated developer tools and should build inventory and review processes that periodically re-check third-party MCP servers as their tool catalogs expand, rather than treating an initial security review as sufficient for the life of the integration. Longer term, organizations adopting AI-assisted code review at scale should design the underlying access model so that a review agent’s default credentials are scoped no more broadly than the review task itself requires, making project-boundary crossings an explicit, auditable exception rather than an ambient capability available to any tool call the agent happens to make.

CSA Resource Alignment

This disclosure is a direct, real-world instance of the attack pattern CSA analyzed in Confused Deputy Attacks on Autonomous AI Agents, which frames the confused-deputy problem as a four-stage chain: an adversary embeds instructions in content the agent processes, the agent inherits the operator’s authority when it acts on those instructions, that authority propagates across systems, and compromised outputs can inject into subsequent systems in turn [5]. The Azure DevOps case maps onto that chain almost exactly — a hidden PR comment is the injection vector, the reviewing developer’s Azure DevOps token is the inherited authority, cross-project pipeline execution and wiki retrieval are the propagation step, and the exfiltrating PR comment is the re-delegation point where the stolen data becomes retrievable by the attacker. That research note’s core recommendation, replacing broad access grants with narrowly scoped ones and treating agent credentials as distinct from human credentials, is substantially the same mitigation this disclosure’s researchers arrived at independently [5].

The finding also extends CSA’s Agentjacking: MCP Injection Hijacks AI Coding Agents research note, which documented a structurally similar attack in which instructions injected into Sentry error events hijacked MCP-connected coding agents into executing attacker commands with developer privileges [6]. Both cases share the same underlying failure: an AI coding agent treats content retrieved from an external, attacker-influenceable data source as authoritative operator guidance, and both were demonstrated against the same class of agents, including Claude Code. Where the Sentry case exploited a public, unauthenticated event-ingestion endpoint, the Azure DevOps case exploits a first-party, officially maintained MCP server, showing that inconsistent injection defenses are not confined to third-party integrations but can appear inside a vendor’s own supported tooling.

Finally, the specific defect — spotlighting applied to some tools in an MCP server’s catalog but not others — is an instance of the uneven security coverage CSA’s MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure research note describes as endemic to the current MCP ecosystem, where the protocol itself provides no native, enforced distinction between trusted operator instructions and untrusted tool output, leaving each server implementation to apply that distinction tool-by-tool and inconsistently [7]. Organizations assessing their own MCP deployments, whether first-party or third-party, should use the identity and access management, input validation, and runtime monitoring domains of the AI Controls Matrix (AICM) v1.1 as a baseline for the credential-scoping, content-provenance, and behavioral-monitoring controls this disclosure shows are still missing from mainstream developer tooling [8].

References

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

[2] Manifold Security. “When Your AI Reviewer Works for the Attacker: A Confused-Deputy Bug in Microsoft’s Azure DevOps MCP Server.” Manifold Security Blog, July 31, 2026.

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

[4] Latest Hacking News. “Azure DevOps MCP Flaw: How to Lock Down Your AI Review Agent Before Microsoft Patches It.” Latest Hacking News, July 26, 2026.

[5] Cloud Security Alliance AI Safety Initiative. “Confused Deputy Attacks on Autonomous AI Agents.” Cloud Security Alliance, March 23, 2026.

[6] Cloud Security Alliance AI Safety Initiative. “Agentjacking: MCP Injection Hijacks AI Coding Agents.” Cloud Security Alliance, June 12, 2026.

[7] Cloud Security Alliance AI Safety Initiative. “MCP Security Crisis: Systemic Design Flaws in AI Agent Infrastructure.” Cloud Security Alliance, May 4, 2026.

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