What happened
The Kiro agent follows instructions embedded in a malicious workspace, reads a local environment secret, writes it into an attacker-controlled Powers URL, and invokes the configuration action that transmits it.
2026-08-27
HighPrimaryAmazon Kiro Prompt Injection Lets Malicious Workspace Content Exfiltrate Local Secrets Through Kiro Powers
Analysis of the Amazon Kiro prompt-injection flaw that let attacker-controlled workspace content read local secrets and transmit them through Kiro Powers configuration.
Amazon Kiro IDECredential exposureIndirect prompt injection composed with agent file access and IDE network behaviorDeveloper workstation running Amazon Kiro IDE 0.7.45 on Windows
Why it matters
Exposure of local API keys or other workspace secrets to an attacker-controlled endpoint and unauthorized mutation of security-relevant IDE configuration.
Missing authorization check
Payload-bound authorization before an agent reads credential material, changes Powers configuration, or sends sensitive values to a new external destination.
Would PP block it?
The injected text could still influence the model, but the consequential operations would stop outside the agent at the authorization boundary. A request containing an unexpected external URL or credential value would not have a matching approval receipt and would fail closed.
Incident analysis
Timeline and technical read
Timeline
2026-08-27
Mindgard publishes the coordinated disclosure after Amazon validates the report.
2026-08-27
Amazon's remediation is documented as shipped in Kiro IDE 0.8.140.
Technical breakdown
- A crafted .code-workspace file points Kiro Powers configuration at an attacker-controlled registry URL.
- Attacker-controlled repository content is interpreted as agent instruction after the user sends an otherwise ordinary message.
- The agent reads a local secret, substitutes it into the registry URL, and invokes the legitimate Kiro Powers configuration action.
- The IDE's network request carries the secret to the attacker-controlled endpoint in both trusted and untrusted workspace modes.
Authorization boundary
Where the authorization boundary should have been
This incident is categorized as Credential exposure. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.
- If enforced at
- Agent file-read, IDE configuration-write, and outbound-network tool boundaries
- Still needs
- Permission Protocol does not remove the prompt injection from the workspace; it constrains the actions the compromised agent can execute.
- Receipt required for
- Reading credential files, changing Kiro Powers registry configuration, and transmitting data to an external endpoint
A Tool-Call Gate can hold the secret read, configuration write, and outbound request until a signer approves the exact payload and destination.
Start small
Put the relevant gate at this action boundary.
This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.