AI coding assistants are increasingly being connected directly to development platforms so they can review pull requests, inspect pipelines, search project documentation and help developers resolve issues faster. That convenience, however, also creates a new security problem: the AI may process instructions that the human reviewer cannot see.
A recently disclosed high-severity weakness affecting the Microsoft Azure DevOps Model Context Protocol server demonstrates this risk. According to the security advisory, an attacker can place malicious instructions inside an invisible pull-request comment. When an AI coding assistant later reviews that pull request, it may interpret the hidden text as a legitimate instruction and use the reviewer's own permissions to access or expose information from other projects.
What Is the Azure DevOps MCP Server?
Model Context Protocol, commonly shortened to MCP, provides a structured way for AI assistants to interact with external systems and tools.
In an Azure DevOps environment, an MCP-connected agent may be allowed to retrieve information from:
This enables an AI assistant to perform useful tasks such as summarising code changes, reviewing documentation, checking development activity or assisting with troubleshooting.
The security concern is that the agent does not merely read public information. It may operate using the permissions of the person who connected it. If the user has access to several private projects, the AI agent may inherit the ability to retrieve information from all of them.
That becomes dangerous when untrusted content can influence what the agent does.
The Attack Begins With an Invisible Pull-Request Comment
Azure DevOps pull-request descriptions support Markdown and embedded HTML comments.
An attacker can therefore insert instructions inside a comment such as:
The text between those markers does not normally appear in the visible pull-request interface. A human reviewer reading the page may see nothing suspicious.
However, the advisory explains that the hidden comment may still be returned in full when the pull-request description is retrieved through the API. The AI assistant receives the raw content, processes the invisible instructions and may mistake them for part of the user's legitimate request.
This is known as an indirect prompt-injection attack.
Unlike a direct attack, where someone openly gives a chatbot a malicious instruction, an indirect attack hides the instruction inside external content that the AI is asked to analyse. This could be a pull request, document, webpage, email, support ticket or database record.
The user may simply ask:
But the pull request may secretly contain an instruction telling the agent to access another project, retrieve sensitive information and place it somewhere the attacker can obtain it.
The human reviewer never intentionally authorised that action.
How the Attack Could Cross Project Boundaries
The attacker only needs legitimate access to one project where they can create or modify a pull request.
They may have no permission to view another private project. The reviewer, however, may be a senior developer, administrator or engineering manager with access to several repositories.
When that reviewer asks an AI assistant to examine the malicious pull request, the agent operates using the reviewer's broader permissions.
The hidden instruction can then attempt to make the agent:
The advisory warns that this could allow someone with access to only one project to manipulate an AI agent into retrieving information from projects that the attacker could not directly access.
The vulnerability therefore does not necessarily involve breaking Azure DevOps authentication. Instead, it abuses a trusted AI agent that already has legitimate access.
Why This Is Called a "Confused Deputy" Problem
The situation is also an example of a long-established security concept known as the confused deputy problem.
A deputy is a trusted system that has authority to perform certain actions. The problem occurs when an attacker tricks that system into misusing its authority.
In this case:
The AI agent is not necessarily compromised in the traditional sense. It is simply unable to reliably distinguish between trusted user instructions and malicious text contained in the material it is reviewing.
The advisory notes that this risk is increased because pull requests are often reviewed by more senior personnel who usually have broader access than the contributor who opened the request.
Why Traditional Code Review May Not Detect It
The malicious text may not appear in the normal Azure DevOps interface, making it difficult for a reviewer to recognise that the pull request contains hidden instructions.
The visible code may also be completely harmless.
A developer could inspect every changed file, test the application and find no suspicious behaviour. The actual attack exists inside metadata or an invisible portion of the pull-request description rather than inside the application's source code.
This means traditional security checks may miss it because:
The weakness sits at the boundary between application security, identity management and AI behaviour.
Microsoft's Existing Protection Did Not Cover the Vulnerable Tool
The advisory states that Microsoft had already anticipated this general category of threat and introduced a defence known as Spotlighting.
Spotlighting places untrusted external content inside clear delimiters so the AI model can better distinguish between information it should analyse and instructions it should follow.
The protection had reportedly been applied to MCP tools that retrieve pipeline and wiki content. However, it was not applied to the tool responsible for returning pull-request descriptions.
That omission left the exact data source used by the attack without the same protection.
This highlights an important lesson for AI security: protection must be applied consistently across every tool that can introduce untrusted content.
Securing nine out of ten data sources may still leave the entire agent vulnerable if the remaining source can inject instructions into the same AI session.
No CVE or Official Fix Was Available in the Advisory
The vulnerability was reportedly disclosed to the Microsoft Security Response Center.
However, as of the advisory dated 23 July 2026, no CVE identifier had been assigned and no official fix had been released.
This does not necessarily mean that every Azure DevOps user is actively being attacked. It does mean that organisations using MCP-connected AI agents should not wait solely for a product update before introducing their own safeguards.
Where no official patch is available, access control, tool restriction, monitoring and content inspection become especially important.
The Main Risk Is Data Exfiltration
The most serious concern is the unauthorised exposure of private information.
An MCP-connected AI agent may have access to sensitive development data such as:
If the same agent can also post comments, update work items or interact with attacker-controlled content, it may have both the ability to retrieve data and a channel through which that data can be exposed.
The advisory identifies three dangerous capabilities when combined inside an AI agent:
An agent containing all three can potentially be manipulated by a single malicious instruction embedded in otherwise ordinary content.
Least Privilege Must Also Apply to AI Agents
One of the most important protections is to restrict the permissions available to the AI agent.
Organisations should avoid giving a code-review assistant unrestricted access to every Azure DevOps project simply because the connected user has that level of access.
Instead, agent tokens should be scoped to the specific project being reviewed.
For example, an AI assistant reviewing Project A should not automatically be able to retrieve:
Even if malicious instructions are successfully injected, tightly scoped permissions can prevent the agent from reaching valuable information outside the authorised project.
The advisory specifically recommends applying the principle of least privilege to agent tokens and limiting access to the project under review.
Only Enable the MCP Tools Required for the Task
An AI code reviewer may need to read a pull request and inspect the associated source-code changes. It may not need permission to execute pipelines, read every wiki or post comments.
Organisations should create task-specific tool sets rather than exposing every available MCP capability to every agent.
For a code-review-only assistant, unnecessary capabilities may include:
The fewer tools an agent can use, the smaller the potential impact of a successful prompt injection.
The advisory recommends loading only the required MCP tool domains and removing pipeline execution, wiki access and comment-posting functions from agents intended solely for code review.
Pull-Request Descriptions Should Be Treated as Untrusted Input
Developers already understand that data submitted through a public web form should not automatically be trusted.
The same principle must now be applied to content processed by AI agents.
A pull-request description may look like internal development documentation, but it is still user-controlled content. It should not be allowed to issue instructions to a privileged AI agent.
Security teams should consider detecting or removing hidden HTML comments before pull-request descriptions are sent to the model.
Reviews could also flag descriptions containing:
This type of inspection will not eliminate every prompt-injection technique, but it can reduce exposure to straightforward hidden-comment attacks.
Agent Activity Must Be Logged and Reviewed
AI agents should not be treated as invisible background tools.
Their actions need to be recorded in enough detail for security teams to understand:
The advisory recommends auditing pull-request descriptions for hidden HTML comments and examining agent tool-call logs for unexpected cross-project activity.
Potential warning signs may include an agent reviewing one project but suddenly querying unrelated repositories, pipelines or wiki pages.
Without detailed logs, such behaviour could appear to be normal activity performed by the reviewer's legitimate account.
A Practical Response for Development and Security Teams
Organisations using Azure DevOps MCP integrations should review their current configuration rather than assuming the AI assistant is safely isolated.
Immediate measures should include:
It may also be sensible to temporarily disable the affected pull-request-description capability in higher-risk environments until stronger safeguards or an official remediation becomes available.
The Wider Lesson for Enterprise AI
This vulnerability is not only an Azure DevOps issue.
Any AI agent that can read untrusted content and use privileged tools may face a similar risk.
Examples include assistants connected to:
The more authority an AI agent receives, the more carefully organisations must control which content can influence it.
Prompt injection should therefore be treated as an access-control and system-design problem, not merely as unusual chatbot behaviour.
Final Thoughts
The Azure DevOps MCP weakness shows how an invisible line of text can become a serious security threat when processed by a privileged AI agent.
The attacker does not need to compromise the reviewer's password or bypass Azure DevOps permissions. Instead, the attacker tricks the AI assistant into using legitimate permissions in an unintended way.
This is what makes indirect prompt injection particularly dangerous: the human user may see nothing suspicious, while the AI receives and follows a hidden instruction.
Until an official fix or comprehensive protection is available, organisations should limit agent privileges, reduce unnecessary MCP capabilities, inspect pull-request content and monitor every tool call made by AI assistants.
AI agents can improve development productivity, but once they are allowed to access private projects and perform actions on behalf of users, they must be governed with the same care as any other privileged application.
Comments