The bait was a .env file holding an OpenAI API key. Researchers put it in a repository next to two other small files, opened the project in Amazon's Kiro IDE, and sent the built-in AI agent a message. Any message. The agent found the key, wrote it into the project's own settings file, and then made the IDE send it to a server the researchers controlled. No approval popup, no warning, nothing asking whether reading secrets or making an outbound request was acceptable.
The chain is the work of Mindgard, which disclosed it publicly on 27 August after reporting it to Amazon on 11 December 2025. Amazon completed remediation in January 2026 and shipped the fix in Kiro 0.8.140. The tested build was 0.7.45 on Windows, and no CVE was assigned at disclosure. Mindgard's write-up and disclosure record carry the detail, and NSFOCUS has since published a breakdown of the full chain.
Two ordinary clicks and a hello
The victim has to do two things, and neither looks like a mistake. Open the project through File then Open Workspace From File, rather than Open Folder, which does not trigger it. Then type anything at all to the agent.
Kiro is Amazon's agentic development environment, built on Code OSS and driven by Claude models. It extends itself through bundles called Powers, and a workspace can set kiroAgent.powersRecommendationUrl to tell the IDE where to fetch its Powers registration data. The malicious repository abuses both. A specially named subfolder tells the agent to read an index.md and carry out what it finds there; that file instructs the agent to search the workspace for anything shaped like a key, drop the result into a placeholder inside the workspace file, and run the Powers configure action. The workspace file points powersRecommendationUrl at an attacker-controlled address ending in that same placeholder, in the demonstration hxxps://serve-customized-image-safety[.]requestcatcher[.]com/powers_registry[.]json?XXX. The IDE then fetches the URL with the stolen key in the query string.
Nobody broke anything
There is no memory corruption here, no code execution bug, and no malicious prompt typed by the user. Every step is a feature working as designed. Mindgard's framing is that the failure is an end-to-end breakdown of trust boundaries: repository content becomes agent instructions, those instructions read local files, the results are written into security-relevant IDE settings, and a different part of the IDE makes the network request. Each hop is legitimate. The chain is not.
Trusted Workspaces did not help. Mindgard reproduced the exfiltration in both trusted and untrusted modes, because that control governs how much a user says they trust a project, not what happens once repository text reaches the layer where the agent interprets instructions. And because the data leaves through the IDE's normal network path, endpoint detection and data loss prevention tooling has little to separate it from ordinary developer traffic.
The fourth chain into the same IDE
This is a pattern rather than an incident. Mindgard reported a steering-file variant in December 2025 that exfiltrated file contents through Markdown image URLs, and an earlier finding let the agent be steered into writing to mcp.json for arbitrary command execution. Intezer has published a full chain in which a poisoned web page led the agent to rewrite its own MCP settings file and reach remote code execution. A separate June 2026 flaw allowing writes to sensitive paths, CVE-2026-10591 at CVSS 8.8, has been patched; it is not the issue described here. Nor is Kiro alone: a booby-trapped Git repository was shown days ago to hijack several rival coding agents outright.
Patch to 0.8.140 and move your secrets
Kiro users should be on 0.8.140 or later. Beyond that, both Mindgard and NSFOCUS land on the same rule: treat repository content as untrusted code. Credentials should not sit in files an agent can read, which means keeping .env files and API tokens out of any workspace an agent is pointed at. And model self-restraint is not a control: permission checks on security-relevant settings have to be enforced by the platform, so that an agent cannot rewrite its own trust boundary. Our coverage of stealer malware hiding inside AI assistant workspace folders makes the same point from the other direction.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.