90 incidents on record · 2026 Headlights Incident reports by Ellie Harris · Melbourne
10 new this week Library last updated 13 July 2026
← The incident library
HD-INC-075
Technology · United States · 2025 · Unconstrained / manipulated action

Amazon's AI coding assistant shipped with planted instructions telling it to wipe users' computers and cloud accounts

By Ellie Harris · Filed Malicious commits 13 July 2025; version 1.84.0 released 17 July 2025

Alleged: Amazon Web Services (Amazon Q Developer) developed or deployed the AI system implicated in this incident. Details are drawn from public reports; parties are presumed innocent of any wrongdoing not established by an official finding.

Amazon's AI coding assistant shipped with planted instructions telling it to wipe users' computers and cloud accounts

What happened

According to AWS’s security bulletin and reporting by 404 Media, an unauthorised contributor planted instructions in the open-source code behind Amazon Q Developer, Amazon’s AI coding assistant, and those instructions shipped to users inside the official Visual Studio Code extension, which had been installed nearly a million times. The planted text told the agent, in plain language, that its goal was to clean a system to a near-factory state: delete the user’s files, then use any cloud credentials it found to delete cloud resources such as storage and servers. A script added to the build was set to feed this to the agent with its safety confirmations switched off. The tampered version, 1.84.0, was published on 17 July 2025. AWS later explained that the person had obtained access through an inappropriately scoped access token exposed by the project’s automated build system, a route security researchers separately demonstrated and AWS confirmed a threat actor had used.

By AWS’s account, the destructive instructions were distributed but never did damage: a syntax error stopped the planted code from executing, and the company said no customer resources were impacted. The person claiming responsibility gave 404 Media a different account, saying the payload was deliberately defective, a warning designed to expose what they called the project’s security theatre, and that far more damage had been possible with the access they held. Some commentators questioned AWS’s version too, saying the code appeared to have run harmlessly on some machines. What is not in dispute is the handling: AWS pulled version 1.84.0 without public notice at the time, and the replacement’s changelog initially described the fix as miscellaneous non-user-facing changes. A public bulletin followed on 23 July, after 404 Media’s story, and was updated two days later to disclose the real access route and assign CVE-2025-8217. AWS revoked and replaced the credentials and said the inert code still sitting in existing 1.84.0 installs should be removed by updating. The person responsible has not been publicly identified, and as of mid-2026 no arrests have been publicly reported.

What an auditable version would have shown

On the accounts reported, an extension installed nearly a million times had shipped with instructions planted to command its agent, and the only reason the story is about a near miss rather than mass deletion is, by AWS’s account, a syntax error in the planted code. An auditable version answers the question that took researchers and reporters a week to reconstruct: where did this instruction come from? A signed record of each instruction source the agent accepted, the build artefact, the file, the commit behind it, would have shown a directive arriving from a build script rather than an authorised maintainer, and would have shown it before release, at the moment the tampered build first spoke to the agent.

Where the gap was

As the incident was reported, nothing distinguished instructions baked into the agent’s own distribution from commands typed by the developer at the keyboard. An AuthorityGate checks the source of an instruction before the agent acts on it: a directive to delete files and cloud resources that arrives from a build script, rather than from the authenticated user, is designed to fail the check regardless of how it is worded. A ConductRecord preserves what the agent was told and by what channel, so a company’s answer to “what shipped and what did it do” comes from signed records rather than from interviews and a reconstruction of the project’s history.

What governance should have looked like

The reported failure sits with the supply chain, but the lesson belongs to the agent: software that can destroy things on a user’s behalf must treat its own configuration as an untrusted input. An agent with filesystem and cloud access should act only on instructions whose source it can verify, refuse destructive commands that arrive without recorded authority, and log every accepted directive in a form the vendor can audit centrally. And when a vendor does ship a tampered build, the disclosure standard should be a bulletin on day one, not a changelog line that says nothing happened.

The reference implementation of AuthorityGate and ConductRecord is open source. It lives at github.com/saffronandindia/headlights-oss, Apache 2.0 licensed and free to install. The repository is public now.

Sources

The mailing list

Fresh incident reports every week. One email to match.

We add new incidents to the library regularly, and send a single short email each week with what's new. The library stays free and open; this is just how you keep up with it.

No tracking. Unsubscribe in one click.

The record

An auditable system would have produced a signed, tamper-evident record the moment this happened: what the system did, the version that did it, the basis it acted on, and the action taken, and Amazon Web Services (Amazon Q Developer) could have produced it on demand.

This is the record the system as deployed did not produce in a signed, auditable form.

What this teaches
Capture what happened when it happens
What the system did, the version that did it, the basis it acted on, and the action taken, recorded at the moment, not reconstructed after.
Sign it, so no one has to trust the record-keeper
A tamper-evident entry. Edit it later and the signature breaks. The record does not ask for the benefit of the doubt.
Make it verifiable by anyone
A court, a regulator, a customer's lawyer can check the record themselves, without taking the company, or us, at our word.

Headlights summarises publicly reported AI incidents. All summaries are independently written, attributed to their original sources, and intended for research and educational purposes. Allegations are identified as such until established through official findings.

Last reviewed June 2026. This report is based on the sources listed above and reflects information available at the time of review; later developments may not be captured. Where a person is described as charged with or alleged to have done something, that allegation is unproven unless a conviction or a court or regulatory finding is stated. Headlights publishes journalism and commentary, not legal advice.

Want to write back?

Direct to my inbox.

ellie@useheadlights.com →