High
High: attackers took over a real developer's AI tool session and stole access tokens, and it applies to organizations whose developers use AI coding tools. How we rate severity
AI coding assistant hijacking: attackers and worms turn developer agents into a way in
Mandiant describes an attacker hijacking a live AI coding assistant session, and a new worm steals AI tool config files. Treat developer AI tools as privileged.
What happened
Two 2026 reports show AI coding assistant security becoming a supply chain issue: attackers are using developers’ AI tools as an entry point and treating their configuration as a target.
In its September 2026 special report on AI risk, Mandiant describes an intrusion in which a threat actor compromised a software-as-a-service provider and “hijacked an active AI coding assistant session on a developer’s workstation.” According to Mandiant, the assistant, “operating as a trusted interpreter within the environment,” recommended an external package the attacker had poisoned. Once that was accepted, the attacker used the developer’s session to install an infostealer from a poisoned PyPI package, harvest GitHub OAuth tokens, and deploy the self-propagating Shai-Hulud worm across about 100 internal code repositories. Mandiant says the actor then poisoned a package in the organization’s official namespace, which led to a second infection when another employee pulled it. Mandiant’s recommended controls include verification hooks that check AI-recommended dependencies against checksums and allow-lists, isolating local credentials from extensions, and restricting workstation egress. In a separate case in the same report, Mandiant says an attacker poisoned an internal AI repository and tampered with an assistant’s command-line hooks to run code through the assistant’s normal workflow.
On October 8, 2026, Socket reported that a release of the TensorLake npm SDK (version 0.5.144), used to build AI agent applications, had been compromised with a payload linked to the same worm family. Socket says the payload targets cloud and Kubernetes credentials, SSH keys and other secrets, as well as configuration and MCP files belonging to several AI development tools. It then republishes compromised versions of other packages tied to the victim’s publishing identity. Socket also warns that the payload watches its stolen GitHub token and is designed to wipe the user’s home directory if the token is revoked before its persistence is removed.
Why it matters to leaders (our analysis)
AI coding assistants run with a developer’s trust, credentials, and repository access, and developers tend to accept their suggestions. That makes a hijacked session an efficient way to get malicious code installed, and an assistant’s configuration and hook files both a source of secrets and a place to tamper. Neither is covered by controls that assume a human chose every package.
The response is mostly existing supply chain discipline applied to a new layer: approved dependency sources, short-lived scoped tokens, and endpoint monitoring that includes AI tool configuration. Leaders should ask which AI coding tools are in use and what each session can reach, because the answer is usually “everything the developer can.”
What to tell your board
Developers' AI coding tools can become a way into our code, so we verify the packages they suggest, keep long-lived access keys away from them, and watch their settings.
What your board will ask
- Which AI coding assistants do our developers use, and what credentials and repositories can those sessions reach?
- Could a dependency an AI assistant recommends be installed without being checked against an approved list?
- Do we watch for changes to AI assistant configuration and hook files the way we watch for other persistence?
- How many long-lived publishing and OAuth tokens sit on developer machines today?
Controls that help
- Validate AI-recommended dependencies against checksums and an approved allow-list before installation, and route package traffic through an internal registry. NIST SP 800-218 SSDF — PW.4
- Keep long-lived OAuth tokens, API keys, and publishing credentials away from AI assistant sessions and extensions. Use short-lived, scoped tokens. NIST CSF 2.0 — PR.AA
- Monitor AI assistant and MCP configuration directories and hook files for unexpected changes, and treat them as a persistence location in endpoint detection. ISO/IEC 27001:2022 A.8.9 Configuration management
- Restrict developer workstation network egress, and scan internal repositories for worm activity after any package compromise. ISO/IEC 27001:2022 A.8.22 Segregation of networks
- In your worm-response playbook, remove persistence on an infected host before revoking stolen tokens, since Socket reports this payload is designed to wipe data when its token is revoked. ISO/IEC 27001:2022 A.5.26 Response to information security incidents
Download one-slide summary
Sources
Change log
- Oct 17, 2026. First published.
All AI tool supply chain risks
Coming soon
The weekly AI security briefing
The five AI risks security leaders should know, with the questions your board will ask. Signups open soon.
Signups open soon. We'll never share your email. See our Privacy Policy. Privacy Policy