Most of what I write about is a mistake made by someone building an app with an AI coding tool. Amazon Q Developer's story from last summer is a genuinely different category, worth its own post: an attack aimed at the tool itself, not at anyone using it, which makes it a supply-chain risk rather than a builder's mistake.
What actually happened
In July last year, malicious code was inserted, via prompt injection, into the Amazon Q Developer VS Code extension's public GitHub repository. That malicious code shipped live to real users in a subsequent extension release. Amazon publicly acknowledged the incident once it became widely known.
Why this is a different category than everything else I write about
Nearly every incident on this blog involves a builder's own app having a missing access rule or an exposed key. This one didn't involve any app built with the tool at all. It involved the tool's own development and release pipeline being manipulated, meaning anyone who installed that specific compromised release was affected, regardless of how careful they'd been building their own project. You can do everything right in your own app and still be exposed by a compromise in the tool you're using to build it.
Why this matters even though it's not something you personally caused
This is a genuinely hard risk to defend against as an individual builder, since it depends entirely on the tool vendor's own internal security, not on anything you configure in your own project. It's still worth understanding, because the natural next question, "how would I even know if this happened to a tool I use," deserves a real answer rather than assuming it's someone else's problem entirely.
What's actually within your control
- Keep your coding tools and extensions updated, but be aware that updating is exactly the mechanism through which a compromised release would reach you, which is an inherent tension with no clean individual-level fix.
- Follow security advisories from the specific tools and extensions you rely on, so you're aware quickly if something like this is disclosed, rather than finding out much later.
- Where a tool or extension has an unusual permission request, one broader than what its stated function seems to need, treat that as worth a second look, the same instinct as checking a bot token's permissions before accepting them.
- Understand that this category of risk exists at all, distinct from the access-control mistakes that make up most of this blog, so it doesn't get missed entirely from the mental model of what can go wrong.
Why I'm writing about this even though there's no personal checklist fix
Most of what I write ends with something you can go check on your own app right now. This one doesn't, and I think that's worth being honest about rather than manufacturing a false sense of control. Supply-chain risk in the tools themselves is real, it's largely outside any individual builder's ability to prevent directly, and the responsible response is awareness and good update hygiene, not a false confidence that careful personal practices alone fully cover this category.