Mindgard demonstrated a prompt-injection path that makes Amazon Kiro IDE send a local project secret to an external endpoint. The researchers reproduced the behavior in Kiro 0.7.45 on Windows, across trusted and untrusted workspaces. Amazon fixed the reported issue in Kiro 0.8.140.
The proof of concept needs two user actions: open a crafted .code-workspace file through Kiro’s workspace-file command, then send any message to the agent. Mindgard did not report exploitation in the wild or quantify affected installations. The demonstrated path still matters because the message itself does not have to ask Kiro to read or transmit sensitive data.
Two actions start the chain
Kiro gives its coding agent access to repository content and tools. The test repository turns those expected capabilities into a path across several trust boundaries.
A deliberately named directory tells the agent to read an index.md file. Instructions inside that file direct the agent to search the workspace, read additional content, edit the workspace configuration, and invoke Kiro Powers. The repository also contains a .env file holding a sanitized OPENAI_API_KEY for the demonstration.
The crafted workspace file sets kiroAgent.powersRecommendationUrl to an external registry URL with a placeholder. After the user sends a message, the injected instructions lead the agent to replace that placeholder with the secret it read from .env.
Workspace trust did not stop this sequence. Mindgard wrote that “the trusted workspace mechanism did not prevent the demonstrated behavior,” and reported reproducing it in both trust states.
Powers carries the secret
The final movement comes from a legitimate Kiro feature. The agent calls kiroPowers(action="configure") after changing the registry setting. Kiro then fetches the configured Powers registry URL, placing the sanitized OPENAI_API_KEY in the outbound query string.
The registry fetch completes the transfer.
Figure details
A developer opens a crafted .code-workspace file and later sends a message to the Kiro agent. Repository-controlled instructions influence the agent to read a secret from .env and write it into kiroAgent.powersRecommendationUrl. The agent invokes kiroPowers(action="configure"). Kiro fetches the configured registry URL, and the request carries the sanitized OPENAI_API_KEY in its query string. The source demonstrates this chain in Kiro 0.7.45 on Windows and says Amazon fixed it in 0.8.140.
The network request proves that the local value reached an externally observable endpoint in Mindgard’s test. It does not establish that attackers used this path against Kiro users. The source also limits the demonstrated entry route to opening a workspace file rather than opening the repository folder directly.
Mindgard says Amazon validated the HackerOne report and implemented the fix in Kiro 0.8.140. Amazon’s CNA team was still assessing CVE eligibility when Mindgard published the research.
Trace settings and outbound requests
Start recognition with repository and workspace changes. Search reviewed or newly opened projects for .code-workspace files that set kiroAgent.powersRecommendationUrl, especially when the value points outside an approved domain. Inspect version-control status and file timestamps for agent-written changes to that setting.
Correlate those changes with agent transcripts or tool records containing kiroPowers(action="configure"). Then examine DNS, proxy, firewall, and endpoint network telemetry for registry requests from Kiro. Query strings deserve special handling because this proof of concept placed OPENAI_API_KEY directly in the URL, where proxies and other intermediaries may also record it.
The verification test is specific: inventory Kiro installations and confirm every instance is 0.8.140 or later; on systems that opened untrusted workspaces, confirm that kiroAgent.powersRecommendationUrl resolves only to an approved registry and that retained network history contains no request with local secret material. A clean result shows a fixed build, approved registry configuration, and no secret-bearing outbound request in the available review window.
If review finds an unauthorized registry URL or exposed value, revoke and replace the affected credential, preserve the workspace and agent records, and scope other secrets accessible from that project. Constrain agent outbound access and repository-triggered configuration changes through the controls available in the development environment.
Agent boundaries need enforcement
This chain crosses repository content, model interpretation, file access, configuration writes, tool invocation, and network access. Treating each capability as safe in isolation misses the risk created by their composition.
The durable defense is to make those transitions visible and enforceable. A coding agent should encounter a meaningful boundary before repository instructions alter network destinations or move local data into a request, regardless of whether the workspace carries a trusted label.