An agent inside your IDE can hand itself a tool nobody gave it. All the attacker may need is a hidden instruction on a page the agent will read.

Researchers from Intezer and Kodem recently published their analysis of an already patched vulnerability in Kiro, the agentic IDE from AWS. But what did that patch actually close – the reported attack path, or the mechanism behind it?

The scenario went like this. A developer asks Kiro to summarize documentation at a given link. The page carries a hidden instruction, a textbook case of indirect prompt injection. Kiro treats it as part of the task and writes a new server, with an arbitrary launch command, into its MCP server config. The IDE re-reads the file on its own, connects the server and runs the command with the developer’s privileges.

A single write does two things at once: the agent connects a new tool, and it sets the command that Kiro executes when the config is re-read. mcp.json is only one of the possible paths here. The danger appears whenever untrusted text can push the agent into rewriting the configuration of its own future capabilities, and the platform accepts that edit as trusted.

This mechanism was found in Kiro on the day the product shipped, in July 2025. Researcher Johann Rehberger demonstrated how the agent could register an arbitrary MCP server through mcp.json, and add shell commands to the allowlist through .vscode/settings.json.

After that first report AWS added a confirmation prompt for such writes, but only in the mode where edits go through review. In the autonomous mode, the one enabled by default, no confirmation was required.

The next report reached AWS in February 2026. The developer only ever approved loading the page; after that Kiro wrote the new MCP server and ran its command without asking again. Sometimes the IDE did show a confirmation dialog, yet it re-read the file regardless of the answer. The dialog warned about the write, but could not stop it.

Nine months after the first report researchers confirmed the new fix. Kiro now protects sensitive files at the platform level in both modes, and asks for consent on capabilities the developer has not pre-approved.

Why individual paths get closed before the class does. A researcher’s report comes with a reproducible scenario, and that is simply easier to close with a local patch. Systemic protection means finding every configuration that defines the agent’s future capabilities and putting one control above all of them – an architectural change rather than a file fix.

So when picking an agentic IDE, I would check two things.

– Can the agent modify the configuration from which the environment gets its tools and its automatically launched commands?

– Does the platform govern such changes in every mode, independently of what the model decides?

The second question echoes my earlier post on why “enabled” does not mean “working”. This is the same story from the other side: the confirmation dialog in Kiro was displayed, and the write went through anyway.

After a repeat finding, what should change is the architecture of control, not the list of paths closed against the same underlying mechanism.