An Amazon Kiro prompt injection flaw lets attacker-controlled repository content silently exfiltrate sensitive local data through Kiro Powers, without the user ever submitting a malicious prompt or referencing the malicious content. Disclosed by Mindgard, the issue carries no CVE identifier and works against Kiro IDE 0.7.45 on Windows (the current version is 1.0.337). Kiro is Amazon's AI-powered, agentic integrated development environment, and the flaw shows how an agentic IDE turns a poisoned repository into a data-exfiltration channel.

The mechanism runs through Kiro Powers, which bundle Model Context Protocol (MCP) server configurations, steering files (POWER.md), hooks, and contextual knowledge. The steering file acts like an onboarding manual that gives the agent persistent context about which MCP tools exist and when to use them, and that persistent, trusted context is exactly what the attacker hijacks. According to Mindgard, exploitation needs only two user actions: opening the malicious project through a workspace file via File then Open Workspace From File (rather than opening the folder directly), and then sending any message to the agent. It is reproducible against both trusted and untrusted workspaces, and the difficulty is assessed as low.

Why is this worse than a normal prompt injection?

Because the user does nothing wrong and gets no warning. What makes the flaw notable is that the victim does not have to submit a malicious prompt or even reference the attacker-controlled content; once the crafted workspace file is opened, sending any message is enough to trigger the exfiltration flow. That collapses the usual assumption that an agent only acts on what you ask it, and it means simply opening a shared or cloned project can be the whole attack.

How do developers reduce the risk?

Update to the current Kiro release, and treat untrusted repositories as untrusted input rather than safe code. Practically, open unfamiliar projects as a folder rather than through a workspace file, be cautious with repositories that ship steering files or MCP configurations, and apply least privilege to what an agentic IDE can read and reach. The broader defense is the same as for any agent: assume the content it consumes can carry instructions, and limit what a hijacked agent can do.

Our read

Kiro is a clean example of the agent-era lesson that the dangerous input is no longer just the prompt, it is everything the agent silently reads. An IDE that treats repository files as trusted context is one poisoned POWER.md away from acting on an outsider's instructions, which is why supervised adversary simulation matters for AI tooling: the useful test is not whether a user can be tricked into a bad prompt, but what a crafted repo can make the agent do on its own. For teams adopting agentic IDEs, that blast radius should be measured before the tool touches real secrets, not after.

Reporting by The Hacker News; technical detail per Mindgard's disclosure. Sources linked above.

Related: What is prompt injection? and AI coding assistant security risks.