Researchers at Mindguard disclosed a vulnerability in Amazon Kiro, AWS’s agentic AI-powered integrated development environment, that allows attacker-controlled repository content to exfiltrate sensitive local information to an external endpoint through Kiro Powers.

The exploitation requirements are the entire story:

The user does not have to submit a malicious prompt or reference the attacker-controlled content. Once the crafted workspace file is opened, sending any message is enough to trigger the vulnerable flow.

Exploitation difficulty is assessed as low. The finding was validated against Kiro IDE 0.7.45 on Windows. It has no CVE identifier.

Why “no malicious prompt required” is the whole problem

Most published prompt injection research still carries an implicit assumption that a user does something — pastes untrusted text, asks the agent to summarize a hostile document, points it at a poisoned URL. That framing supports a comforting mitigation: train developers not to feed the agent things they do not trust.

This finding removes the user from the equation. The developer clones a repository, opens it in Kiro, and types something entirely ordinary — “what does this project do,” “add a test for the login handler.” The crafted file is already in the workspace context. The agent has already read it. The injected instructions execute, and sensitive workspace data is transmitted to the attacker without the user explicitly requesting that Kiro access or transmit it.

There is no moment where a reasonable developer could have made a different choice. Opening a repository in your editor is the base case of software development.

The trust boundary that agentic IDEs erased

A conventional IDE reads files. It does not act on their contents. Malicious text in a README is inert, because the editor has no mechanism for a file to instruct it.

An agentic IDE deliberately dissolves that separation. Its value proposition is that it reads your entire workspace, builds context from it, and takes actions on your behalf — running commands, editing files, calling tools, reaching network endpoints. Every one of those capabilities is a feature. Together they mean workspace content is executable input.

Kiro Powers extend the agent’s reach further, which is exactly why they became the exfiltration path. The more an agent can do, the more an injection can do.

This is the same structural failure documented across the agentic tooling space this year: the Kiro remote code execution work from Intezer, where hidden web text caused the agent to edit its own MCP configuration and execute attacker code; CVE-2026-0830, analyzed by NeuralTrust; and the broader trajectory we covered in Unit 42’s DeepSeek/Hermes research on autonomous attack agents and in the CoSnitch Copilot vulnerability.

The common thread: LLM-based agents cannot reliably distinguish instructions from data, because to the model there is no architectural difference between the two. Everything is tokens in a context window. Every mitigation currently shipping — system prompt hardening, delimiter conventions, instruction hierarchies, classifier-based filtering — is probabilistic. None is a boundary.

The missing CVE

The flaw has no CVE identifier. AWS has previously declined to assign one for related Kiro findings.

The vendor position has a coherent argument behind it: prompt injection is arguably a characteristic of how LLMs work rather than a defect in a specific software version, and the CVE system was designed for the latter. Assigning identifiers to every injection path in every agentic product would produce an unmanageable flood.

The practical consequence is that enterprise vulnerability management does not see this. Scanners match installed software against CVE feeds. No CVE means no finding, no ticket, no patch SLA, no risk register entry. Organizations that have deployed agentic IDEs across engineering teams have no mechanism by which this disclosure reaches their security program at all.

Meanwhile the affected population is precisely the wrong one to leave unwarned. Developer workstations hold cloud credentials, signing keys, production database strings, .env files, SSH keys and proprietary source. A developer’s laptop is one of the highest-value endpoints in most organizations, and the machines running agentic IDEs are, by definition, developer laptops.

What is actually exposed

The disclosure describes exfiltration of sensitive workspace data. In practice, what sits in a developer workspace:

  • .env files with API keys and database credentials
  • Cloud provider credential files (~/.aws/credentials, kubeconfig)
  • Proprietary source code
  • Internal API endpoints, service topology and infrastructure-as-code
  • Secrets committed to git history

Any of those reaching an attacker-controlled endpoint is a credential compromise, and it happens without an EDR alert — the network connection originates from a legitimate developer tool making a legitimate outbound request.

What to do

There is no patch to apply and no version to pin to, so mitigation is architectural:

  1. Treat repository content as untrusted input. Cloning unfamiliar code and opening it in an agentic IDE is now equivalent to running untrusted code, and should be governed by the same policy.
  2. Isolate the agent. Open unfamiliar repositories in a container, VM or dev container with no host credentials mounted and no access to the broader filesystem.
  3. Get secrets off developer disks. Short-lived, federated credentials issued at use time cannot be exfiltrated from a .env file that does not exist. This is the single highest-value control and it addresses far more than agentic IDEs.
  4. Monitor egress from developer endpoints. Outbound connections from an IDE process to unfamiliar domains are a detectable signal, if anyone is looking.
  5. Inventory agentic tooling. Most security teams do not know which AI-powered IDEs and coding agents are deployed across engineering, and the CVE gap guarantees that inventory will not build itself.
  6. Restrict agent capabilities. If Kiro Powers, MCP servers or tool integrations are not required for a given workflow, disable them. Exfiltration requires an outbound path.

The uncomfortable summary: the industry has deployed software whose core design premise is that files can tell your computer what to do, and the security model for that premise does not yet exist.

Sources