A prompt injection flaw in Amazon's Kiro IDE allowed attackers to exfiltrate source code and credentials through a feature meant to assist developers. Disclosed by Mindgard in late 2024, the vulnerability affected version 0.7.45 on Windows and required minimal technical skill to exploit.
This wasn't a new attack vector. The issue stemmed from a trust boundary problem that your team can learn from.
What Happened
Kiro IDE includes "Kiro Powers," a feature that lets the AI assistant execute actions beyond simple code suggestions. An attacker could inject malicious instructions into any content the IDE processed, comments in a pull request, documentation files, even dependency manifests. When Kiro's AI parsed that content, it executed the embedded commands without verifying the source.
The exploit chain was straightforward: craft a prompt that instructs Kiro to read sensitive files, then send that data to an external endpoint. Because Kiro Powers operated within the IDE's execution context, it had access to everything the developer could see: API keys in environment files, proprietary algorithms, customer data in test fixtures.
Fergal Glynn from Mindgard noted the vulnerability's low exploitation difficulty. No privilege escalation required. No complex payload obfuscation. Just text that looked like legitimate instructions to an AI assistant.
Timeline
Pre-disclosure: Mindgard identified the vulnerability during routine security research on AI-powered development tools.
Responsible disclosure: Mindgard reported the findings to Amazon through their security disclosure program.
Version 0.8.140 release: Amazon shipped a fix that added input validation and restricted Kiro Powers' execution scope.
Public disclosure: After Amazon's patch deployment, Mindgard published technical details.
The exact dates aren't public, but the pattern matters more than the calendar. Amazon responded with a patch. Organizations running Kiro had to identify affected installations, test the update, and deploy it before the public disclosure increased exploitation risk.
If you're running AI-assisted development tools, you faced the same update window, whether you knew it or not.
Which Controls Failed
Input validation: Kiro treated all text as potentially actionable instructions. There was no distinction between developer-authored prompts and content from external sources. OWASP ASVS v4.0.3 Requirement 5.1.1 mandates that applications validate all input from untrusted sources. A comment in a third-party library is untrusted input.
Execution boundaries: Kiro Powers ran with the same permissions as the developer's session. No sandboxing, no capability restrictions. When the AI decided to read a file or make a network request, it just did. ISO 27001 control A.8.22 requires segregation of development, testing, and production environments. That same principle applies within a development tool: the AI assistant shouldn't have unrestricted access to everything the developer can touch.
Output filtering: Even after Kiro read sensitive data, nothing prevented it from sending that data wherever the prompt instructed. PCI DSS v4.0.1 Requirement 3.3.1 requires masking of sensitive authentication data when displayed. If your IDE can read payment data from test databases, it needs output controls to prevent exfiltration.
Monitoring and logging: Organizations likely had no visibility into what Kiro Powers was doing. NIST 800-53 Rev 5 control AU-2 requires auditing of security-relevant events. An AI assistant reading environment files and making outbound connections qualifies.
What the Standards Require
Input validation (OWASP ASVS 5.1.1): Validate all input from untrusted sources using positive validation. For an AI assistant, this means parsing the source of every prompt component. Developer-typed text gets different treatment than content from external files.
Least privilege (ISO/IEC 27001:2022 A.8.2): Access rights should be restricted based on need. An AI code assistant needs read access to your current file. It doesn't need read access to your entire filesystem or write access to network sockets.
Secure configuration (PCI DSS v4.0.1 Requirement 2.2.1): Configuration standards must be developed and implemented for all system components. If you're deploying AI-powered tools, you need a configuration baseline that defines what they can access and what they can't.
Logging and monitoring (NIST CSF v2.0 DE.CM-1): Networks and network services are monitored to find potentially adverse events. When your IDE makes unexpected network connections, something should notice.
Lessons and Action Items
Inventory your AI-powered development tools. You can't patch what you don't know about. Survey your engineering teams for IDE extensions, code assistants, and automated review tools. Document versions and update policies.
Treat AI assistants as untrusted execution contexts. Don't give them ambient access to secrets. If you store API keys in .env files, your IDE shouldn't be able to read them by default. Use a secrets manager with explicit access grants.
Implement prompt injection defenses now. Add input validation that distinguishes between user commands and external content. Mark comments, documentation, and dependency files as untrusted sources. If your AI tool processes these, it needs to sanitize instructions before execution.
Monitor AI tool behavior. Log file access patterns and network connections from your development environment. An IDE that suddenly reads 50 files and makes HTTP requests to an unfamiliar domain is doing something worth investigating.
Test updates in isolation. When Amazon released version 0.8.140, you needed a way to verify it didn't break your workflows before deploying to 200 developers. Maintain a test environment for development tools, just like you do for production systems.
Review third-party code with AI context in mind. That helpful comment in an open-source library could be a prompt injection payload. Code review now includes checking for text that instructs AI assistants to take actions.
The Kiro vulnerability wasn't sophisticated. It exploited the gap between how we think AI assistants work, as helpful tools that follow our instructions, and how they actually work, as execution engines that follow any instructions they parse. Your development environment needs security controls that account for that reality.
