# A Hidden HTML Comment Was All It Took to Own Your AI Code Reviewer
The pull request looked ordinary. A contributor opens it, writes a clean description, and waits for review. What the human reviewer never sees — because HTML comments render as nothing in the Azure DevOps web UI — is a block of text addressed not to them, but to their AI agent. When that agent pulls the PR to begin its review, it reads the hidden instructions, pivots cross-project, reads a confidential wiki page the attacker couldn't touch, and posts the contents back as a comment where the attacker can collect it.
The whole sequence runs on the reviewer's credentials. The attacker wrote some text and waited.
This is the vulnerability Manifold Security documented this week in Microsoft's official Azure DevOps MCP server — the bridge that lets AI coding agents like GitHub Copilot CLI and Claude Code operate Azure DevOps on a user's behalf. The firm calls it a confused-deputy attack. The deputy is your AI agent, confused by instructions it received in data it trusted.
## The Split That Makes It Work
The delivery mechanism is almost elegant. Azure DevOps PR descriptions accept Markdown, which allows embedded HTML. In the browser, <!-- hidden text --> renders as nothing — it's invisible to a human reviewer scanning the change. The REST API returns the raw text verbatim. The Azure DevOps MCP server passes that text directly to the model.
So there are two views of the same PR description: what the human sees, and what the agent receives. They're different. The attacker writes for the second audience.
The agent is operating with the reviewer's session permissions. When it reads the hidden instructions and acts on them, it's doing things the reviewer is authorized to do. Cross-project pipeline triggers, wiki reads, work item access — whatever scope the reviewer holds, the agent now holds, pointed at targets the attacker wrote down.
Manifold built a proof of concept on a local build of v2.7.0, running the same attack against both Copilot CLI and Claude Code. The exploit isn't tied to one model. The tool trace the firm published shows the full chain: hidden comment triggers pipeline in an unrelated project, agent reads a confidential wiki page, agent posts that page back on the original PR as a comment. One hidden line drove every step.
## Microsoft Had the Fix. Just Not Here.
What separates this from a generic "AI can be manipulated" warning is that Microsoft already knew the problem existed and had shipped a partial defense.
Reading the server's source, Manifold found a technique called spotlighting applied to the wiki-page and build-log tools. Spotlighting is Microsoft's own recommended mitigation for indirect prompt injection: wrapping untrusted content in delimiters so the model can distinguish between data and instructions. PR #1062 introduced a shared helper, createExternalContentResponse, and wired the wiki and build-log tools to run through it.
The PR description tool, repo_get_pull_request_by_id, never calls it. It hands back the description raw.
This is the kind of gap that happens when a fix is applied to the surfaces people were thinking about — wikis, build logs — and the surface that actually matters for attacker-controlled content gets missed. PR descriptions are written by contributors, often external ones. They are exactly the kind of untrusted input that spotlighting exists to handle.
The Hacker News confirmed the same gap is still present in the current source as of July 21.
## Who Actually Gets Hit
The prerequisites deserve a clear read. This doesn't fire at everyone. You need attacker-controlled PR content, a workflow that feeds it to an agent, a reviewer whose access exceeds the attacker's, and — critically — an agent configured with auto-approve posture, meaning it doesn't prompt for confirmation before running tools.
That last condition is load-bearing. An agent that pauses and asks "I'm about to run a pipeline in a different project — proceed?" gives a human a chance to catch it. One running in fully automatic mode does not.
Manifold notes that the escalation is the normal case, not a lucky edge case: reviewers are typically more senior than contributors. An attacker with limited project access who can get a PR in front of a senior engineer with organization-wide read and execute rights has made a meaningful trade. They put text in a box; they get whatever the senior engineer's agent can reach.
Enterprise Azure DevOps environments with broad token scopes and auto-approve agent workflows are where this concentrates. Smaller teams with more restrictive tooling are less exposed, but the server is Microsoft's official implementation and the pattern is replicable.
## HackWire Analysis
This vulnerability is a preview of a class of attacks that's going to define the next few years of enterprise security, and it's worth being direct about why.
The MCP ecosystem is being built fast, by organizations that have years of experience securing systems against humans but almost none against AI agents operating as trusted deputies. The distinction matters: a human reviewer who sees a suspicious PR description can stop. An agent reading the same description through a REST API call has no visual representation, no instinct to pause, no context that "HTML comment" signals anything unusual. It processes text.
Microsoft's partial fix makes this harder to dismiss as negligence. They thought about indirect prompt injection, they built a defense, they applied it inconsistently. That pattern — awareness without coverage — is what to watch for across every MCP server being written right now, by Microsoft and everyone else. The attack surface for AI agent tooling is every piece of user-controlled content the agent might read. That is a lot of surface.
The comparison that comes to mind is the early years of SQLi: developers knew parameterized queries existed, knew injection was a problem, and still shipped raw string concatenation in one function while correctly escaping the others. The root cause was the same — coverage was manual and inconsistent, so gaps were inevitable.
For defenders, the practical guidance is specific. Before enabling AI coding agents in enterprise Azure DevOps workflows, audit what auto-approve posture means for your agent configuration. Per-tool confirmation is friction, but it's the checkpoint that would have surfaced the cross-project pipeline call before it fired. Treat PR descriptions, issue bodies, and wiki pages as untrusted input in any toolchain that routes that content to a model with execute permissions. And watch for createExternalContentResponse coverage gaps if you're running your own MCP servers — that shared helper is now documented, which means auditing whether your tools call it is a concrete action, not an abstract one.
Microsoft will patch this. The broader pattern won't be patched by a single commit.
— HackWire Editorial
## Related Coverage