Hidden Text, Hidden Threats: When Your AI Coding Agent Turns Into an Attacker’s Pawn
A white pixel. One invisible HTML comment in a pull request. A developer asks their AI to “summarize this API documentation” or “review this PR,” and seconds later, the machine is running someone else’s code, exfiltrating secrets, and hopping into internal projects the attacker has never logged in to.
>This isn’t a hypothetical threat model. It happened. Twice. In the same week.
On July 21, researchers disclosed that AWS Kiro, Amazon’s agentic coding IDE, could be tricked into rewriting its own configuration file and executing arbitrary code — all because a developer asked it to read a web page with hidden text. The next day, a separate disclosure showed that Microsoft’s official Azure DevOps MCP server could be hijacked by a single invisible HTML comment in a pull request, turning the reviewer’s own AI agent into a confused deputy that leaks data across projects.
These aren’t edge cases. They’re the first clear signals of a systemic vulnerability in how we design AI coding tools. And if you’re a developer using AI agents — which at this point is most of us — you need to understand what happened, why it matters, and what it means for how we’ll work with these tools going forward.
What Actually Happened
Kiro: The Web Page That Ran Code
AWS Kiro is an agentic IDE that can search the web, fetch URLs, edit files, and run shell commands — all with the promise that anything risky will prompt the developer for approval first. That approval step is the entire security model. It’s the boundary between “helpful assistant” and “remote code execution platform.”
Researchers at Intezer and Kodem Security found that this boundary didn’t exist. Kiro reads its list of MCP servers — the external tools it can load — from a file at ~/.kiro/settings/mcp.json. And Kiro could write to that file using its fsWrite tool with no approval required. When the file changed, Kiro reloaded the configuration and launched whatever server was described, including the exact shell command to start it.
The attack chain is deceptively simple. A developer asks Kiro to summarize an API documentation page. That page contains hidden text — a single white pixel on a white background — with instructions telling Kiro to write a malicious MCP server entry to mcp.json. Kiro reads the page, follows the hidden instructions, writes the file, reloads the configuration, and runs the attacker’s code. The developer only ever approved “fetch this URL.” Everything else happened silently.
In some cases, Kiro did show a pop-up saying the MCP configuration had changed and asking for approval. It made no difference. The configuration reloaded regardless of what the developer clicked.
This isn’t even the first time. In July 2025, researcher Johann Rehberger showed the exact same mcp.json write-to-execution attack on Kiro’s launch day. AWS’s fix only applied to Supervised mode, leaving the default Autopilot mode wide open. Intezer’s 2026 chain used Autopilot. A separate CVE-2026-10591 (CVSS 8.8) was assigned for a similar .vscode/tasks.json attack, but the mcp.json variant was patched without a CVE.
Azure DevOps MCP: The Invisible Comment That Leaks Your Repos
The same week, Manifold Security disclosed a vulnerability in Microsoft’s official Azure DevOps MCP server. The pattern is different, but the root cause is the same: AI agents process untrusted content as instructions.
Azure DevOps pull request descriptions support Markdown, which includes HTML comments. An HTML comment — <!-- hidden text --> — renders as invisible in the browser. A reviewer scrolling through a PR description sees a normal change. But the REST API returns that hidden text verbatim, and Microsoft’s MCP server feeds it directly to whatever AI agent is reviewing the PR.
When the reviewer asks their agent to review the PR, the hidden comment can rewrite the agent’s goal. The agent carries the reviewer’s credentials, so it can act across projects the attacker has no access to. In Manifold’s proof of concept, a single hidden comment made the agent trigger a pipeline in a different project, read a confidential wiki page, and post its contents back as a comment on the original PR — where the attacker could read it.
Microsoft had already shipped a defense for this — a technique called spotlighting that wraps untrusted content in delimiters so the model can separate data from instructions. They applied it to the wiki and build-log tools in PR #1062. But the pull request description tool, repo_get_pull_request_by_id, never got the same protection. As of July 21, the current source code on GitHub still shows the gap.
The team reproduced the attack with both Copilot CLI and Claude Code, so this isn’t specific to one agent. And the researchers noted that as teams move toward automated review — where AI agents fire autonomously on every PR — the planted description triggers on its own, and the leak runs longer before anyone notices.
This Is a Design Problem, Not a Bug
What makes these vulnerabilities disturbing isn’t the technical sophistication. They’re embarrassingly simple. No zero-day exploits. No memory corruption. No supply chain poisoning. Just text on a page that an LLM interprets differently than a human would.
The problem is architectural. AI coding agents are designed with a fundamental assumption: that the human-in-the-loop approval step is a reliable security boundary. These vulnerabilities prove it isn’t.
The root cause plays out in three ways across both incidents:
- Agents can modify their own trust boundaries. Kiro could write to the file that determines what code it’s allowed to run. An approval prompt for that write should have been the minimum, but even that failed — the config reloaded regardless of what the user clicked.
- Untrusted content becomes trusted instructions. Both vulnerabilities rely on the same LLM property: there is no separation between data and instructions for a transformer. An HTML comment and a setup command look the same to the model. Spotlighting and delimiters help, but they’re only as good as the developer who remembers to apply them consistently.
- The agent inherits the user’s full access. In the Azure DevOps case, the attacker doesn’t need their own credentials. They borrow the reviewer’s through text the reviewer never sees. If the reviewer has admin access — which senior developers and team leads often do — the agent’s cross-project reach is enormous.
As someone who manages a small IT team, this hits close to home. I’ve been experimenting with AI coding agents for code review and scripting. The productivity gains are real. But the idea that a single web page or pull request could turn my own tools against me, using my credentials, without me ever seeing it happen — that’s a risk I hadn’t fully internalized until these disclosures landed.
The Pattern: MCP as the Weak Link
Both vulnerabilities share an important detail: they exploit the Model Context Protocol (MCP) ecosystem. MCP is the standard for connecting AI agents to external tools — databases, APIs, PR systems — and it’s being adopted fast because it works well. But the protocol introduces a new class of trust decisions that most developers aren’t equipped to evaluate.
When you connect an MCP server to your AI agent, you’re giving that agent the ability to act on your behalf, with your credentials, across the systems the server connects to. The security model assumes the agent will only act on your explicit instructions. But as these disclosures show, “your instructions” and “a hidden text block in a PR description” are indistinguishable to the LLM running the show.
This isn’t an MCP protocol flaw per se — it’s a consequence of giving LLMs access to tools without a robust mechanism for distinguishing trusted from untrusted content. The protocol is the delivery mechanism, not the root cause. But it’s also where defenses need to be built, because the protocol is the layer where trust boundaries can be enforced.
What This Means for Developers
If you’re using AI coding agents — as I discussed in my HeimWall tutorial for catching secrets before they reach your AI tools — Kiro, Cursor, Copilot, Claude Code, Continue.dev — here’s what these disclosures mean for you:
First, check your approval settings. Kiro’s Autopilot mode is the default and it’s fundamentally insecure for operations that modify configuration files. Switch to Supervised mode if it’s available, and be skeptical of any agent that can write to its own config without your explicit say-so. Some tools now mark sensitive file paths like mcp.json and .vscode/tasks.json as protected, which means each write requires an explicit approval. But check whether your version actually enforces this — the approval was technically there in Kiro’s case, but it didn’t actually stop the reload.
Second, audit your MCP server configurations. Every MCP server you connect extends your agent’s reach. Review what each server can do, what credentials it carries, and whether it applies spotlighting or content isolation to untrusted inputs. If a PR review MCP server doesn’t separate instructions from content, it’s a vector waiting to be triggered.
Third, never auto-approve tool calls. Manifold Security explicitly confirmed that the Azure DevOps attack requires the agent to be “cleared to run tools without asking.” If your review pipeline auto-approves PR review actions, you’re one hidden comment away from a data leak. Every cross-project tool call — reading a different repo, triggering a pipeline, accessing a wiki — should prompt the human before executing.
Fourth, think about automated workflows. The researchers noted that as teams move toward fully automated review — AI agents that fire on every PR with no human reading each result — the attack runs silently. If you set up automated PR review, ensure the agent operates in a sandbox with limited credentials. A read-only token for the repo being reviewed, not a token with cross-project access.
Fifth, watch the MCP tools you load. The beauty of MCP is that anyone can write a server. The danger is that anyone can write a server. The FakeGit campaign, which I covered earlier this week, showed over 800 malicious repos posing as AI skills or MCP servers, as I covered in the FakeGit campaign deep dive. The threat isn’t just the code they run — it’s the permissions you grant them when you connect them to your agent.
The Bigger Picture
We’re in an awkward adolescence for AI coding tools. The productivity is undeniable. I can write a complex database migration or debug a network issue in minutes with an agent that would have taken me hours writing raw code. But the security model hasn’t matured to match the capability.
The core tension is this: agents are useful precisely because they can act autonomously. If every action required a human click, you’d lose most of the productivity gain. But giving an agent the ability to act autonomously, with network access and file write permissions, means you’re trusting an LLM — a statistical text predictor prone to following hidden instructions — with your development environment.
The parallels to the early days of web security are striking. In the late 1990s, SQL injection and XSS were considered niche bugs. Developers rolled their eyes at parameterized queries and output encoding. Then the attacks scaled, the damage grew, and what was once an afterthought became a fundamental requirement for any production web application. The same arc is playing out now with AI agent security, except the timeline is compressed. SQL injection took years to become a standard concern. These vulnerabilities are dropping weekly as I explored in my Three Security Warnings roundup.
AWS and Microsoft both patched these issues. Kiro now protects mcp.json with path-level approvals. Microsoft has acknowledged the spotlighting gap. But the underlying design pattern — agents that act on untrusted content with the user’s full authority — is not going away. It’s the architecture of every AI coding agent on the market.
Where Do We Go From Here?
I don’t think the answer is to abandon AI coding agents. The productivity gains are too real, and they’re only going to get better. But I also don’t think the answer is “just be more careful” — because that’s what developers thought before SQL injection became an industry-wide crisis, and we all know how that turned out.
What we need is a platform-level rethinking of how agents handle untrusted content. Content isolation should be the default, not an opt-in feature. Tool permissions should be scoped at the protocol level, not the whim of each tool’s developer. And the approval boundary — the “allow” button — needs to actually mean something. If clicking “allow” doesn’t prevent the action it’s supposed to guard, the entire security model is theater.
For now, if you’re using AI coding agents, stay updated. The fixes for these specific vulnerabilities are in Kiro v0.11.130+ and whatever Azure DevOps MCP server version Microsoft ships after this disclosure. But the broader pattern — hidden text, invisible comments, data that looks like instructions — isn’t going to be fixed in a single version bump. It’s going to take the entire ecosystem waking up to the fact that when you give an AI agent tools — as the xAI lawsuit over who is responsible when AI causes harm makes painfully clear — you’re giving anyone who can talk to that AI agent access to those tools too.
And someone is already testing what they can do with them.