Security researchers have shared details of a vulnerability in Amazon Kiro, an AI-powered, agentic IDE that combines coding help with automated actions. The central concern is that prompt injection risks can enable an attacker to influence the Kiro agent through repository content and ultimately cause sensitive local information to be transmitted to an external destination.
Notably, this issue does not have a CVE identifier. According to the researchers, it impacts Kiro IDE 0.7.45 on Windows, while the latest version mentioned is 1.0.337. A fix was also reported as implemented in 0.8.140 by Amazon after responsible disclosure.
How the vulnerability works in Kiro
The reported weakness centers on what happens when attacker-controlled project files are interpreted as instructions and are allowed to affect security-sensitive operations elsewhere in the IDE. In the words attributed to the researcher, repository-controlled content can be used to influence the agent so that sensitive local data is later sent off-machine.
In practice, the exploitation hinges on the behavior of Kiro Powers. Beyond “skills,” Kiro Powers packages configuration elements and contextual instructions, including:
- MCP server configuration details (Model Context Protocol)
- Steering files (noted as “POWER.md”)
- Hooks
- Contextual knowledge
The steering file is described as a kind of onboarding guide that persists context for the agent. It also indicates what MCP tools are available and when they should be used, which means the agent may act on tool-related instructions triggered during normal interaction.
Two user actions required to trigger exfiltration
According to Mindguard, successful exploitation requires two user actions. First, the user must open a malicious project via a workspace file, using File → Open Workspace From File, rather than simply opening the folder directly. Second, once the project is opened, the user must send a message to the agent.
Importantly, the vulnerability is reported as reproducible against both trusted and untrusted workspaces. So the presence or absence of a trust label does not eliminate the underlying risk when the triggering conditions are met.
Why the user may not notice the data transfer
A particularly worrying aspect is that sensitive data can be exfiltrated without the user explicitly requesting that Kiro access or transmit it. Once the conditions are satisfied, exploitation can proceed even if the user does not submit a malicious prompt or reference the attacker-controlled content directly.
The reported sequence can be summarized as follows:
- Attacker-controlled project content is interpreted as instructions.
- Those instructions influence security-sensitive IDE operations.
- The agent reads sensitive local workspace information.
- The agent writes the information into security-relevant IDE configuration.
- A subsequent IDE capability turns that modified configuration into network activity, sending the data externally.
This chain suggests a failure in the trust boundary across multiple stages—where content originating from the repository ends up affecting local configuration and then network behavior, effectively collapsing the separation that developers expect between untrusted inputs and sensitive actions.
Exploitation is assessed as low difficulty
Mindguard assessed the exploitation difficulty as low. The reasoning is that the user does not need to perform highly specialized steps beyond the two actions already described (opening via a workspace file and sending any message). Once those conditions are met, the vulnerable flow can be triggered by sending any message to the agent.
As a result, the issue is not limited to a scenario where a user carefully follows a malicious instruction. Even casual interaction after opening the crafted workspace file can be enough to start the chain that leads to data exfiltration.
Previous related steering-file issues
The Kiro report builds on earlier findings by Mindguard. Previously, steering-file directives were described as capable of causing local information to be incorporated into a Markdown image request and transmitted to an external server.
In that earlier case, an attacker could coerce the AI to send sensitive data by carefully crafting a steering file that instructs it to read a local file and render that data into a Markdown image format. The new disclosure expands the story by showing how similar concepts can play out through the wider agent workflow and its tool and configuration mechanisms.
What changed after disclosure
After responsible disclosure, Amazon implemented a fix for the issue in Kiro IDE version 0.8.140. Since the affected version was identified as 0.7.45 on Windows, upgrading to a patched release is the most direct mitigation described in the reporting.
With the additional detail that the latest version at the time of reporting is 1.0.337, the practical takeaway is to keep Kiro IDE updated, especially if you use Kiro Powers or open workspace files from third parties.
Broader lesson: AI tools increase attack surface
This disclosure fits a wider pattern of security problems in AI development tools. As AI assistants and agentic systems increasingly interpret and execute within the same workflow, the boundary between “helpful context” and “powerful action” can blur.
In such environments, repository files can provide context to a model, while the agent can read files, invoke tools, and activate other functionality inside the application. That combination can create situations where attacker-controlled content influences behavior that was intended to be reserved for trusted user intent.
The reporting also references a series of other vulnerabilities in AI tooling where prompt injection, tool calls, configuration writes, and trust boundaries were exploited to reach outcomes such as remote code execution, token theft, sandbox escapes, or control of an agent through indirect interactions. The common theme is that attackers look for paths that turn language-model influence into system-level consequences.
Practical safety steps for developers
While patching is essential, the reported trigger conditions highlight additional user-level precautions you can apply:
- Prefer updated IDE versions and apply security updates promptly.
- Be cautious with workspace files from untrusted sources, especially when using “Open Workspace From File.”
- Limit agent interaction after opening third-party projects, particularly when Kiro Powers features are involved.
- Review and understand tool/context features like steering files and MCP-related configurations, since they can shape what the agent is allowed to do.
These steps do not replace a fix, but they can reduce the likelihood of encountering the vulnerable chain described by the researchers.
Conclusion
The disclosed Kiro issue shows how prompt injection risks can go beyond confusing an AI assistant. In this case, attacker-controlled repository content can influence the agent, leading to sensitive local workspace information being funneled into configuration changes that trigger network transmission—potentially without the user realizing that anything sensitive was accessed or sent.
Because a fix was implemented in 0.8.140, the strongest recommendation is to upgrade. At the same time, the broader lesson is clear: as AI IDEs gain more tools and context-aware automation, security efforts must consider trust boundaries across interpretation, configuration, and execution paths—not just the text the user sees.
Source: https://thehackernews.com/2026/08/amazon-kiro-prompt-injection-can.html
