Your AI Agent Is a Confused Deputy: What Two 2026 MCP Disclosures Teach Us About Agent Security

In July 2026, researchers showed that a few words in an HTML comment, invisible in the Azure DevOps web interface, could make an AI code-review agent trigger a pipeline in another project, read a confidential wiki page, and post it back as a comment. A month later, another team showed that a malicious MCP server could steal secrets by splitting its request into pieces that each look harmless.

‍

Neither is an exotic model-jailbreak story. Both are an old problem in new clothes: the confused deputy. A privileged component is tricked by a less-privileged party into misusing its authority. In agentic systems, the agent is the deputy, and it carries the user's credentials.

What is MCP security, and why is it hard?

Short answer: MCP (Model Context Protocol) security is the discipline of controlling what an AI agent can do through the tools and data sources it connects to, and of treating everything those tools return as untrusted input.

‍

MCP standardizes how agents call tools and read context. That is its value, and its risk: tool descriptions, tool results and server-initiated requests all flow into the same model context where instructions live. The model can't reliably tell data from instructions. Unit 42 (Palo Alto Networks) documented how MCP's sampling feature, which lets a server ask the client's model to generate text, can be abused for resource theft, conversation hijacking and covert tool invocation, and it describes an implicit trust model as the root issue.

Case 1: Hidden comments in a pull request (Azure DevOps MCP)

Reported by Manifold Security and covered by The Hacker News on 22 July 2026:

‍

• An attacker with write access to a project puts instructions in an HTML comment in a pull request description. The Azure DevOps web UI doesn't display it, but the REST API returns it verbatim.
• A reviewer asks their AI agent to review the PR. The agent reads the description through the MCP tool repo_get_pull_request_by_id.
• The hidden text redirects the agent. Because it acts with the reviewer's credentials, it can reach beyond what the attacker could access. In the proof of concept it triggered a pipeline in another project and posted a confidential wiki page as a PR comment.
• Manifold reproduced the chain with both Copilot CLI and Claude Code, and said the cause is that this tool returned PR descriptions without the spotlighting guardrail Microsoft had applied to the wiki and build-log tools.
• Per the report, prerequisites include a workflow that passes PR text to the agent, a reviewer whose access exceeds the attacker's, and tools running without per-tool approval (an auto-approve setting). As of 21 July there was no fixed release and no CVE, and Microsoft called it "a known class of AI risk."

‍

The lesson: the vulnerability isn't in the model. It's the combination of untrusted content, privileged credentials, and unattended tool execution.

Case 2: GhostSplice, or splitting the attack across channels

The ASSET Research Group's GhostSplice technique, reported on 11 August 2026:

‍

• A malicious MCP server fragments a data-theft request into pieces that each look routine, placing them in channels the agent already trusts: a tool description, a tool result, or possibly server-initiated sampling.
• The agent combines the fragments in context and sends the data back. In the reference implementation, a harmless-looking integrity_checker tool's bland fields are later mapped to sensitive files such as SSH keys, source code and .env files.
• In the researchers' own tests, splitting into two pieces raised average compliance from 42% to 82% across eleven models tested via API. Results varied widely by model and by client, and the tests used isolated projects with fake credentials.
• Limits to keep in mind: no real-world intrusion was reported, no CVEs were listed as of 10 August, and the attack assumes the developer already connected the attacker's server and the agent can read the target files.

‍

The lesson: filtering for "bad-looking instructions" can fail when no single message looks bad. Defenses must be structural, not pattern-matching.

The shared pattern: a confused deputy with three ingredients

Remove any one and the attack degrades sharply. That's the useful insight for architects: you do not need to "solve prompt injection" to reduce risk materially. You need to break the chain.

How to harden agents that use MCP

These controls follow the mitigations recommended in the cited disclosures and Unit 42's guidance, framed as an architecture checklist.

‍

1. Treat all tool output as data, not instructions. Don't let one tool's output flow unchecked into another tool's arguments (ASSET's recommendation).
2. Scope credentials to the task, not the person. Use least-privilege, project-scoped tokens for agents instead of a developer's full-access token. Manifold's guidance for the Azure DevOps case includes exactly this.
3. Shrink the toolset per workflow. A PR-review agent doesn't need pipeline-run, wiki-read and comment-post tools. Load only the MCP domains needed.
4. Keep a human in the loop for high-impact actions. The MCP specification says clients should keep a human able to deny tool invocations. Auto-approve is the setting that turned a hidden comment into a cross-project action in the PoC.
5. Vet and pin MCP servers. Treat a third-party server like a dependency with code-execution reach: review, version-pin, and monitor changes to its tool descriptions.
6. Log and monitor tool traces. Look for cross-project or cross-resource activity that doesn't match the user's request.
7. Sanitize and constrain sampling. Per Unit 42: strict templates, response filtering, capability limits and rate limiting on server-initiated sampling.

Threat modeling an agent: questions to ask

In assessments of agentic systems, these questions surface the most issues:

‍

• What untrusted content can reach the agent's context? (Issues, PRs, tickets, emails, web pages, tool descriptions.)
• Whose identity does the agent act as, and what can that identity reach that the content's author can't?
• Which actions are irreversible or exfiltrate data (posting comments, running pipelines, sending HTTP requests)?
• Where does the human actually look, and where is approval skipped?
• What if a trusted MCP server is updated, or compromised?

‍

Drawing this out as a data-flow diagram with trust boundaries makes the confused-deputy paths obvious. Our threat modeling work increasingly starts with the agent and its tools as first-class components.

Testing: what to validate

Reviewing an agent design on paper isn't enough, since behavior depends on the model, the client's safety controls, and the configuration. GhostSplice results differed substantially across clients, which is an argument for testing your deployed combination. Useful validation includes an MCP security assessment of the servers and tool permissions, an agentic system security assessment of end-to-end workflows, an AI security architecture review of the design, and AI-native application penetration testing that attempts injection through every content channel the agent reads.

Conclusion: what to do differently on Monday

• Inventory every agent with tool access and list the MCP servers it uses.
• For each, write down the identity it runs as and the untrusted content it reads.
• Turn off auto-approve for any tool that writes, executes or sends data.
• Cut each agent's toolset to the minimum.
• Add the agent to your threat models and your pentest scope.

‍

MCP didn't create the confused deputy. It made it easy to build one in an afternoon.