A Comment You Cannot See Can Hijack Your AI Code Reviewer

Microsoft's official Azure DevOps MCP server exposes a tool that returns pull request descriptions to an AI agent. According to Manifold Security, that tool ships without the “spotlighting” guardrail Microsoft already applied to its pipeline and wiki content tools. An attacker writes instructions inside an HTML comment. Azure DevOps renders the comment as nothing in the browser. The REST API returns it verbatim, and the MCP server passes it to the model as ordinary input.

The result is a textbook confused deputy. The agent is holding the reviewer's credentials, so the injected instructions execute with the reviewer's access, not the attacker's. No authentication was broken and no software vulnerability was exploited in the traditional sense. The trust boundary between “content the agent reads” and “instructions the agent follows” simply was not enforced on one code path.

Francisco Rosales, an offensive security engineer at Manifold Security, published the research on July 21, 2026. It describes an indirect prompt injection in Microsoft's official Azure DevOps MCP server: the tool that returns pull request descriptions hands attacker-controlled text straight to the agent with no marker separating it from the reviewer's own instructions.

The detail that makes this more than a theoretical concern is that Microsoft had already built the defense. Manifold notes that spotlighting, the technique of wrapping untrusted content in explicit delimiters so the model can tell data from instruction, was introduced in PR #1062 and applied to the pipeline and wiki content tools. It was not applied to the pull request description tool. This was a coverage gap in a control that already existed, which is the kind of gap that is very hard to spot by reading source code.

Manifold reported the issue to MSRC, which acknowledged and triaged it. As of The Hacker News coverage on July 22, no CVE had been assigned and no fix had shipped. A Microsoft spokesperson described it as a known class of AI risk and recommended that customers limit project access and review proposed changes before asking an AI tool to act on them. The practical problem with that advice, as the researchers point out, is that the payload is invisible in the interface where a human would do the reviewing.

The attack takes four steps and requires nothing more privileged than the ability to open a pull request. There is no malware, no stolen token, and no exploit payload in the usual sense. The entire attack is text, and its power comes from the difference between what a browser renders and what an API returns.

A confused deputy is a trusted component that holds more authority than the party asking it to act, and can be persuaded to spend that authority on the requester's behalf. Every access control in this attack worked exactly as designed. The reviewer had access to the Payments project. The agent was running as the reviewer. The pipeline ran because a user with permission asked it to.

This is why permission reviews do not catch it. If you audit who can read the Payments wiki, the answer will be correct and the attack will still work. The gap is not in the access control list; it is in the assumption that everything reaching the agent's context represents the intent of the person the agent is acting for. The same assumption is what makes AI agents useful, which is precisely what makes this hard.

We have written about the neighboring failure modes before: how a packaging mistake shipped an entire codebase to npm, how a typosquatted model repo reached the top of Hugging Face trending, and how AI-generated vulnerability reports flooded the curl project. The through line is that the AI supply chain keeps failing at the boundaries between components, not inside them.

No single control is sufficient, because the injection itself cannot be reliably detected. Layer four controls so that a successful injection has nothing valuable to reach. The table below maps each layer to the specific step of the published proof of concept it would have broken.

The missing guardrail is specific to one tool in one server. The shape of the problem is not. Any MCP server that pipes attacker-influenced text into an agent that also holds write-capable tools has the same exposure: issue bodies, commit messages, ticket comments, fetched web pages, and dependency README files are all channels an outsider can write to.

Microsoft documented a closely related case in its own research on the Claude Code GitHub Action, where injected content in issues and pull requests steered the agent into reading environment variables from the CI runner. The pattern repeats because the fix is architectural rather than a patch: the channel that carries untrusted content has to be structurally distinct from the channel that carries instructions, and the tool set has to be scoped so that a successful injection reaches nothing worth taking.

If you are choosing an agent stack for a team right now, our comparison of Cursor, Claude Code, and OpenCode covers the day-to-day workflow tradeoffs, and the companion piece on the AsyncAPI npm compromise covers the other half of this month's story: what happens when the malicious code arrives through a package rather than a prompt.