Breaking News

The DevOps Problem with AI Agents Is Delegated Authority

Written by Maria-Diandra Opre | Jul 29, 2026, 11:33:27 AM

A hidden comment in an Azure DevOps pull request was enough to steer an AI review agent into another project, retrieve confidential information, and post it back where the attacker could read it. The attacker never needed elevated access; but rather simply exploited that of the reviewer.

Manifold Security’s analysis of Microsoft’s Azure DevOps MCP server found that a contributor could place instructions inside an HTML comment in a PR description. The comment is invisible in Azure DevOps’ web interface but returned by its API. When a reviewer asks an agent to assess the PR, the MCP server passes that hidden text to the model alongside the pull request details (The Hacker News, 2026).

The agent then faces a problem humans do not, since it cannot reliably treat the PR as both information to analyze and a potentially hostile source of instructions. It sees language, and language is the medium through which it is controlled.

In Manifold’s proof of concept, the planted text told the agent to trigger a pipeline in another project, read a confidential wiki page, and publish it in a comment on the attacker’s PR. Each action fell within the reviewer’s permissions. The exploit lay in the sequence: a contributor with access to one project used the reviewer’s agent to reach material they could not access directly.

This goes beyond a prompt-injection flaw in one Microsoft tool. It exposes a gap in how DevOps teams deploy agents: conventional identity controls do not account for untrusted content that can influence a trusted identity. Access management usually asks whether an identity can read a repository, run a build, or access a secret. Agentic systems require another question: who can influence how that identity uses its permissions? A contributor may be entitled to open a pull request, but not to direct a senior engineer’s automation towards confidential resources. MCP can collapse those interactions into a single workflow.

Microsoft had already implemented a partial defense. Some MCP tools use “spotlighting” to label external material as untrusted and distinguish it from instructions. The pull-request tool did not. One missing wrapper created a route around the guardrail.

This is how agent security fails in practice: controls are uneven. A team may protect logs and wiki pages while overlooking a PR description or CI error message. An attacker only needs one unguarded route into the agent’s context.

The pattern has already appeared on GitHub. In 2025, Invariant Labs showed that malicious instructions in a public GitHub issue could steer an AI agent into accessing private repository information and leaking it through a pull request (Invariant Labs, 2025). This is not a quirk of Azure DevOps or one coding model. It is a predictable failure mode when autonomous agents combine broad access with untrusted inputs.

Simon Willison’s “lethal trifecta” applies directly: private data, untrusted content and a route to send data out (Simon Willison, 2026). DevOps agents increasingly hold all three. They read PRs, tickets and logs; access repositories, wikis and pipelines; then write comments, trigger jobs or call external services.

AI-assisted development needs tighter authority boundaries. A PR-review agent should use a task-scoped, preferably read-only identity limited to the repository under review. Pipeline runs, cross-project access and external posting should require separate approval.

DevOps agents increasingly hold all three. They read PRs, tickets, and logs; access repositories, wikis, and pipelines; and then write comments, trigger jobs, or call external services.