A Worm Hijacked an AI Coding Session and Spread Through 100 Repos. Your Agent Could Be Next.

Accurate as of September 2026.

Google's Mandiant published its AI Risk and Resilience report on September 16. It reads like an incident log. Three case studies matter if you're running AI coding agents anywhere near production, and none of them required tricking a model into saying something bad.

1. A hijacked coding session became a worm launcher. An attacker compromised a SaaS company's dev environment, took over a live AI coding assistant session, and got the assistant to recommend a poisoned PyPI package. Installing it dropped an infostealer that harvested GitHub OAuth tokens, then used them to spread the self-propagating Shai-Hulud worm across roughly 100 internal repositories, pulling secrets and source code out as it went. A second employee later pulled a poisoned package from their own company's namespace and got reinfected. The assistant wasn't jailbroken. It recommended a dependency the way it recommends dependencies all day, and nothing downstream checked it.

2. A red team socially engineered an agent, not a person. Mandiant's own testers went after an internal AI assistant that managed code repos and CI/CD. They convinced it that they were running an authorized security test, and the assistant handed over a personal access token and cloned sensitive repos to an external GitHub account they controlled. The assistant had the permissions to do that as part of its normal job. It needed a plausible story, nothing more.

3. A broken null value turned into a $50,000 bill. A finance-sector agent reconciling ledger anomalies hit a corrupted value that broke its formatting tool, dropped into a reasoning loop, and fired off more than 15,000 API calls in under an hour, running up roughly $50,000 in charges and locking the database hard enough to stall live transactions. No attacker involved, just an agent with database write access and no circuit breaker.

Neither attacker needed a clever prompt injection, and the third incident had no attacker at all. What all three had in common: an agent that could act, credentials that outlived the task, and no independent check on what got installed, exfiltrated, or spent. That's an infrastructure gap, not a model-safety gap.

What actually would have stopped each one:

1. Verify before install, every time. Cryptographic checksums or an allowlist for anything an agent recommends pulling in, checked outside the agent's own context. This alone would have stopped the worm at step one.
2. Scope credentials to the task, not the session. Short-lived, narrowly-scoped tokens instead of long-lived PATs an agent can reuse across every action it takes for the next eight hours.
3. Put a human or a hard gate on anything irreversible. Cloning a repo externally, pushing to a namespace, deleting data - these need an approval step that isn't itself part of the agent's own reasoning loop, because the red team result shows the agent can be talked out of "no."
4. Cap cost and call volume per agent, not per account. A circuit breaker on API calls or spend per task would have caught the reasoning loop in minutes instead of an hour.
5. Isolate agent secrets from IDE/CLI extensions. The coding-assistant hijack worked because the session's credentials were reachable from the extension layer. Keep them out of reach of anything the assistant loads dynamically.

None of this is exotic. It's the same access-control discipline you'd apply to a new hire with root access on day one, which is functionally what an agentic coding session is. The teams treating "the agent recommended it" as equivalent to "a senior engineer approved it" are the ones that end up in next year's report.