Slide 14 of 28
Part 3 — Attack ScenariosSlide 14
PART 3
Attack Scenarios
Slides 14–17 · Six documented incidents and the pattern they share
Slide 14 · Scenarios 1–2
Scenario 1: Amazon Q VS Code — Scenario 2: GitHub MCP Tool Descriptor Poisoning
Scenario 1 Amazon Q VS Code Extension — Compromised Update Channel (2025)

What happened: Version 1.84.0 of the Amazon Q Developer VS Code extension was found to contain code that exfiltrated developer credentials — API keys, tokens, and access credentials from the developer's environment. The extension was distributed through the official VS Code marketplace with a valid signature.

The supply chain failure: The attack entered through the extension's update channel. Developers (and AI coding agents using the extension) received the malicious update as a routine, signed package from a trusted source.

Why agents amplify this: AI coding agents that are configured to use Amazon Q as a tool received the compromised extension automatically — and then ran with the compromised code operating in the background of every subsequent agentic task.

Type 4 — Compromised registry/update channel
Scenario 2 GitHub MCP Tool Descriptor Poisoning — Invariant Labs (2025)

What happened: Invariant Labs demonstrated that hidden instructions embedded in a GitHub issue body — invisible to human readers but processed as authoritative context by LLMs — could cause an AI coding assistant to read and exfiltrate the developer's private repository contents. The assistant was using a GitHub MCP server to access issues as part of its normal workflow.

The supply chain failure: The data the tool returned was the attack vector. The tool itself was operating exactly as intended — fetching issue content and providing it as context. The poisoning happened in the content, not the tool.

The key finding: Any tool that fetches external content and provides it as context to an LLM is a potential tool descriptor / data poisoning vector.

Type 1 — Poisoned tool data supply chain
← Back Scenarios 3–4 →