Amazon Q: a wiper prompt shipped inside a signed VS Code extension

What happened

Amazon Q Developer is an AI coding agent distributed as a Visual Studio Code extension. ReversingLabs documented an incident in which an attacker was able to commit malicious code into the extension's repository and have it carried into a public release.

According to the account, the attacker abused a GitHub token with excessive permissions in the configuration of a CodeBuild service to get a change merged. The injected content was a system-prompt-style instruction directing the AI agent to wipe the environment — deleting local files and configurations and removing the user's AWS resources. The malicious build was published and reached the extension's large installed base of roughly a million users. The destructive instruction did not execute: the planted code contained a syntax error that prevented it from running, so no customer environments were damaged. AWS revoked and replaced the compromised credentials, removed the malicious code, released a patched version, and tightened its CodeBuild security. Commentators characterized the outcome as fortunate timing rather than a defense that held.

Root cause

• LLM03 Supply Chain. An over-privileged credential let an attacker inject content into the build pipeline of a trusted, signed extension, which was then distributed to end users.
• LLM01 Prompt Injection. The payload was a crafted instruction aimed at the agent's system prompt — steering the model toward destructive behavior rather than exploiting a memory-safety bug.
• LLM06 Excessive Agency. The agent had the standing capability to delete local files and act on the user's AWS resources, so a single injected instruction could, in principle, cause real destruction.

How it would have been caught

Least-privilege scoping and secret scanning on the CI/CD tokens (for example with tools such as TruffleHog or GitHub secret scanning) would have blocked the merge vector. On the model side, a red-team check that inspects the shipped system prompt and agent tool grants for destructive-capability instructions — and an agent sandbox that denies file-deletion and cloud-teardown without confirmation — would have caught the payload before release.

How to prevent it

• Scope CI/CD and repository tokens to least privilege and rotate them; never leave a build credential able to publish arbitrary code.
• Review and pin the agent's system prompt and tool permissions as security-relevant artifacts in the release gate.
• Run the agent's destructive actions (file deletion, cloud resource removal) behind a sandbox and explicit human confirmation.

The Breachwire test (red → green)

In a sandbox, load an extension build whose system prompt carries a wipe instruction and confirm the agent attempts destruction (the RED control proving the supply-chain payload is live). Apply token least-privilege plus an action sandbox, then confirm the same payload cannot delete anything, while the agent still performs legitimate coding actions (the positive control against a lock-everything false green).