TL;DR

Mindgard demonstrated an indirect prompt injection vulnerability in Amazon Kiro IDE in which attacker-controlled repository content caused the Kiro agent to read sensitive local data, modify workspace configuration, invoke Kiro Powers, and ultimately send the sensitive value to an attacker-controlled endpoint. The PoC was reproduced in Kiro IDE 0.7.45 on Windows, including in both trusted and untrusted workspaces. (mindgard.ai)

The victim had to open the crafted workspace using File → Open Workspace From File and then send a message to the agent. The disclosed research does not state how the malicious workspace reached the victim, so delivery methods such as git clone, ZIP download, or shared repository is a possibility, but should not be assumed. The issue was fixed in Kiro IDE 0.8.140 on January 26, 2026 and publicly disclosed on August 27, 2026. (mindgard.ai)

Core Attack Pattern

Mindgard created a malicious Kiro workspace containing repository content that directed the agent to locate a sensitive value, substitute it into kiroAgent.powersRecommendationUrl, modify the .code-workspace configuration, and invoke the Kiro Powers configuration action. The workspace also contained a sanitized OPENAI_API_KEY used as the test secret.

After the victim opened the crafted workspace and sent a message to Kiro, the agent followed the embedded instructions, read the sensitive value, modified the workspace configuration, and invoked Kiro Powers. The IDE then fetched the configured external URL, causing the test secret to appear in the outbound request. The user did not explicitly request that the secret be accessed or transmitted.

The attack exploited the boundary between repository content and agent instruction. Content that should have been treated as untrusted project data instead influenced the agent's operational behavior.

The demonstrated flow was:

Attacker controlled workspace → repository content reaches Kiro → indirect prompt injection → goal substitution → sensitive file access → configuration modification → tool invocation → outbound data exfiltration

The attack is more significant than a conventional prompt injection case because the injected instructions did not merely alter model output. They caused the agent to orchestrate state changing operations and network activity using legitimate application capabilities.

There is no evidence in the disclosed PoC of traditional privilege escalation, lateral movement, persistence, or command and control. The agent abused capabilities it already had. It is best characterized as authorization drift within existing privilege.

AI Kill Chain

1. Reconnaissance — Active. Mindgard mapped how Kiro handles repository content and how the Powers configuration action gets triggered, then built the PoC workspace specifically around that behavior — targeting the exact mechanism that lets project files reach the agent's context and the exact setting (kiroAgent.powersRecommendationUrl) that would carry the exfiltrated value out.
2. Trust Manipulation — Active. Kiro treated the crafted workspace's repository content as legitimate project material the moment it was opened, in both trusted and untrusted workspace modes. Malicious instructions were embedded directly in that content, exploiting the implicit trust the agent extends to anything sitting inside a workspace it's been pointed at.
3. Input & Instruction Weaponization — Active. The payload didn't fire on its own — it sat inert in the repository content as delayed, indirect prompt injection until the victim opened the workspace and sent the agent a message. That message was the trigger that pulled the embedded instructions into the agent's live context.
4. Reasoning-Time Execution — Active. Once in context, Kiro didn't just process the injected text as inert data — it adopted it as an objective. The agent substituted the attacker's goal (locate the sensitive value, rewrite the Powers URL, invoke Powers) for whatever the user's actual message had asked for, with no indication the user requested any of it.
5. Tool Invocation — Active. Acting on the substituted goal, the agent read the sensitive local value, modified the .code-workspace configuration file to point kiroAgent.powersRecommendationUrl at the attacker's value, and invoked the Kiro Powers configuration action — three distinct, state-changing tool calls chained together from a single injected instruction.
6. Privilege Escalation — Bypassed entirely. The agent never needed to acquire new privileges to pull this off. Every action — reading the file, editing the config, invoking Powers — was something Kiro was already authorized to do; the attack worked by redirecting existing capability, not by escalating it.
7. Lateral Movement — Bypassed entirely. The entire chain played out inside the single compromised workspace. There's no evidence in the PoC of the agent or attacker moving to another host, identity, or environment to extend the attack's reach.
8. Persistence — Bypassed entirely. The .code-workspace file was modified, but that change was a means to exfiltrate the secret in the moment, not a mechanism for maintaining durable access after the session ended. No persistence foothold was demonstrated.
9. AI-Native C2 — Bypassed entirely. The IDE did reach out to an external, attacker-controlled URL, which is genuine outbound communication — but it was a single fetch carrying the stolen value, not an ongoing channel the attacker could use to send further commands back to the agent.
10. Action on Objectives — Active. The Powers-invocation fetch delivered the sanitized OPENAI_API_KEY test secret to the attacker-controlled endpoint, completing the objective: data theft carried out end-to-end by the agent itself, using its own legitimate tool access.

How To Prevent This Class of Attack

Treat Repository Content as Untrusted

Repository files should be treated as data, not as authoritative instructions. Project content should not independently authorize sensitive operations simply because it appears inside a workspace.

Inspect for Prompt Injection

Repository content should be inspected before entering the agent context for instructions attempting to control model behavior, access secrets, modify configuration, invoke tools, or trigger external communication.

Bind Tool Use to User Intent

Agent actions should be evaluated against the user's stated objective. A benign development request should not implicitly authorize a sequence such as: read secret → rewrite external endpoint → invoke network-capable tool

Sensitive reads and security relevant configuration changes should require stronger authorization or human approval.

Restrict Sensitive Data and Network Flows

Secrets such as API keys and credentials should not be freely accessible to agents. Runtime controls should also restrict agent driven outbound traffic to approved destinations and detect sensitive values leaving through URLs or other external requests.

These controls provide multiple break points even if prompt injection succeeds.

UnifAI Policies

AI_APP_SEC_001, AI_APP_SEC_002, AI_APP_SEC_029, AI_APP_SEC_032, AI_APP_SEC_059, AI_APP_SEC_066, AI_APP_SEC_070, AI_APP_SEC_069, AI_DAT_SEC_001, AI_IAC_015

Hidden in the Repo, Obeyed by Your Agent

The Kiro incident demonstrates that prompt injection becomes significantly more dangerous when an LLM is connected to tools, application state, sensitive files, and network capable functionality. The initial payload was ordinary repository content, but the model transformed that content into a sequence of operational actions.

The core failure was not simply that the model accepted an untrusted instruction. It was that untrusted repository content gained enough influence over an authorized agent to drive actions outside the user's stated intent.

The demonstrated progression is: Implicit Trust Abuse → Indirect Prompt Injection → Goal Substitution → Tool Execution Abuse → Data Exfiltration via AI

The strongest defense is therefore layered: inspect untrusted content, preserve the data/instruction boundary, constrain tool use to user intent, protect sensitive data, and enforce outbound destination and data loss policies.