AI coding agent malware turned npm trust into a delivery path

At a glance

What this is: This is a supply-chain analysis of a self-propagating npm worm that abused a compromised maintainer identity and AI coding agent persistence hooks to spread without requiring npm install.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern repository-linked secrets, developer tokens, and AI tool credentials as runtime identities, not just package artifacts.

By the numbers:

• 11 malicious releases were identified across the maintainer’s 61 packages, and hundreds more were republished by the worm within hours.
• keyv alone carries roughly 127 million weekly npm downloads, a measure of reach rather than compromised hosts.
• 09:02 UTC on August 4

👉 Read Cycode’s analysis of the keyv npm worm and AI coding agent compromise

Context

AI coding agent identity risk now extends beyond what gets installed from a package manager. In this incident, the attacker used a compromised maintainer account, poisoned legitimate releases, and planted persistence in AI agent and IDE configuration so compromise could begin when a repository was opened, not only when code was installed.

For identity teams, the important question is no longer whether a package is signed or whether install scripts are blocked. The governance gap is that developer environments, AI coding tools, and CI runners now execute with trust relationships that are effectively non-human identities, yet many controls still assume package installation is the only meaningful execution boundary.

That makes this a supply-chain and identity problem at the same time. The article is a useful reminder that developer tokens, GitHub provenance, AI assistant credentials, and repository-level persistence all sit in the same attack surface when a trusted maintainer identity is hijacked.

Key questions

Q: What breaks when AI coding agents can execute from repository configuration instead of package installs?

A: Package-centric controls lose their main assumption: that execution starts when a dependency is installed. If repository-open files can launch scripts, then editor settings, assistant configuration, and workspace metadata become executable trust surfaces. Teams need to govern those files like code, because they can trigger secret theft before SCA or install-script policies ever fire.

Q: Why do signed releases not eliminate supply-chain risk after maintainer compromise?

A: A valid signature proves the artifact was built through the expected process, not that the maintainer identity was uncompromised at release time. When an attacker controls the publishing account, provenance can become part of the attack path instead of a defense. The control gap is identity lifecycle, not artifact formatting.

Q: How should security teams isolate AI tool credentials from developer and cloud access?

A: Treat AI assistant tokens as operational non-human identities with their own vault scope, logging, and rotation cadence. Do not place them in the same profile as cloud CLI keys, GitHub tokens, or registry access. Segmentation matters because this malware shows one workstation compromise can cross from AI tools into build and cloud access.

Q: Who is accountable when a trusted maintainer identity is hijacked and malicious code is published?

A: Accountability sits with the organisation that governs the publishing identity, the release pipeline, and the downstream consumers who rely on it. For practical purposes, maintainers, platform owners, and security teams all need explicit ownership for revocation, monitoring, and recovery. Provenance is not a substitute for lifecycle governance.

Technical breakdown

Compromised maintainer identity as the delivery primitive

This campaign did not require a flaw in npm itself. The attacker used a compromised maintainer identity to publish malicious versions through normal release workflows, which means the trust anchor was the human-linked publishing account rather than the package registry. When package provenance is valid but the publisher is compromised, attestation proves only that a known identity built the artifact, not that the identity itself remained trustworthy. That distinction matters because many supply-chain controls stop at package integrity and do not continuously validate the maintainer context behind the release.

Practical implication: verify who controlled the publishing identity, not just whether the artifact was signed.

Repository-open persistence in AI agent and IDE config

The unusual element is the execution path. Persistence was planted in .claude/settings.json and .vscode/tasks.json, which cross-called setup scripts so opening the repository or starting the coding assistant could trigger the payload without npm install. That bypasses install-script controls because the malicious logic lives in editor and agent configuration, not just package lifecycle hooks. In practice, the repository becomes an execution environment, and AI coding tools become runtime surfaces that can activate secrets-stealing code before any dependency resolution occurs.

Practical implication: treat repository-open behaviour and IDE configuration as part of the execution boundary.

Self-propagating credential theft across developer and cloud secrets

The payload harvests cloud credentials, CI/CD tokens, registry tokens, AI assistant credentials, and host secrets, then uses stolen access to spread further. That is classic worm behaviour, but its target set is broader than traditional developer machines because it now includes Claude, OpenAI, Cursor, Gemini, GitHub Actions OIDC, Vault, Kubernetes, Jenkins, and cloud CLI material. The architectural point is that one compromised development identity can expose multiple downstream non-human identities, turning a single publish event into a cross-environment identity cascade.

Practical implication: segment developer, CI/CD, cloud, and AI-tool credentials so one compromise cannot traverse all four layers.

Threat narrative

Attacker objective: The attacker’s objective was to turn a trusted maintainer identity into a worm distribution channel that steals secrets, spreads itself, and expands access across developer and cloud environments.

1. Entry occurred when the attacker hijacked the maintainer’s GitHub identity and used legitimate publishing access to push malicious package updates to npm.
2. Escalation happened as the worm planted repository-open persistence in AI agent and IDE configuration, allowing compromise without a package install step and enabling self-propagation through reused credentials.
3. Impact followed when the payload harvested developer, cloud, and AI tool secrets, republished itself through stolen npm access, and created a broad supply-chain exposure across build and workstation environments.

Breaches seen in the wild

• Amazon Q AI Coding Agent Compromised — Amazon Q AI coding agent compromised via prompt injection enabling hackers to inject data-wiping commands.
• Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity trust is the real attack surface here: the attacker did not need to break npm, only the assumption that a maintainer account and its publishing workflow remain trustworthy. Signed provenance is useful, but it does not compensate for a hijacked identity that can still produce a valid release. The practitioner conclusion is that publishing identity assurance must be treated as part of the control plane, not as a post-release verification step.

Repository-open execution is a new governance boundary for AI coding agents: this attack works because AI assistants and IDEs now execute on repository state, not only on installed packages. That breaks the old assumption that code execution begins at install time. Security teams should recognize repository configuration as an identity-bearing runtime surface, because agent-triggered execution can occur before traditional endpoint or SCA controls see anything useful.

Developer tooling now carries NHI blast radius: the malware steals cloud keys, CI tokens, npm tokens, Vault material, and AI assistant credentials in one pass. That is a non-human identity consolidation problem, not a single-secret event. The named concept here is repository-open execution risk: when simply opening code can trigger credential compromise, the exposure model shifts from package dependency management to environment governance.

Provenance without identity lifecycle controls is incomplete: the article shows that release attestations can be valid while the upstream identity is already compromised. That means lifecycle controls for maintainers, publishers, and automated release identities must be aligned to revocation, rotation, and monitoring, not assumed safe because the artifact chain looks clean. Practitioners should treat maintainer compromise as a standing NHI governance issue, not only a software integrity issue.

AI agent credentials need the same segregation discipline as cloud credentials: the malware explicitly targets Claude, OpenAI, Cursor, and Gemini alongside traditional secrets. That tells us these credentials are already operational identities with real blast radius, even when they are embedded in developer workflows. The practical conclusion is that AI tool credentials now belong in the same governance model as service-account and developer access controls.

From our research:

• 11 malicious releases were identified across the maintainer’s 61 packages, and hundreds more were republished by the worm within hours, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Our research also found that 4.6% of all public GitHub repositories contain at least one hardcoded secret, which means public code remains a viable starting point for identity compromise.
• For related governance guidance, see 52 NHI Breaches Analysis for recurring patterns in compromised non-human identities and blast-radius expansion.

What this signals

Repository-open execution risk: AI coding tools are no longer just consumers of code. They are runtime surfaces that can activate persistence hooks before install-time controls are even relevant, which means developer environment governance now needs to include editor state, workspace files, and assistant configuration. With 4.6% of public GitHub repositories containing at least one hardcoded secret, per the State of Secrets Sprawl 2025, exposure is already common enough that any new execution path should be treated as a credential-risk multiplier.

A practical programme response is to expand non-human identity governance into developer tooling and AI assistant credentials. The key is to control where tokens live, how they are segmented, and what can trigger execution, because the compromise chain in this article crosses package integrity, IDE behaviour, and secrets harvesting in one sequence.

For practitioners

• Map repository-open execution paths Inventory which editors, AI assistants, and repo bootstrap files can trigger code before npm install runs. Remove cross-wired persistence hooks such as .claude/settings.json and .vscode/tasks.json from trusted workflows unless they are explicitly controlled and reviewed.
• Treat publishing identities as governed assets Review maintainer, release, and GitHub identities with the same lifecycle rigor you apply to privileged service accounts. Revoke or rotate access after any compromise suspicion, and validate who can publish, sign, and modify release automation.
• Separate developer and AI-tool secrets from build credentials Store AI assistant credentials, cloud keys, npm tokens, and GitHub tokens in distinct vault scopes with independent rotation and logging. Keep AI-tool access out of general workstation profiles so one stolen token does not expose the full workstation identity stack.
• Harden the release boundary beyond install scripts Use verified package allowlists, release-age cooldowns, and CI policies that detect new publish anomalies. Do not rely on npm ci --ignore-scripts alone, because repository-open triggers and IDE hooks bypass install-script-only defenses.
• Rebuild hosts that interacted with seeded repos Treat any workstation or runner that opened a seeded repository as compromised and rebuild it rather than cleaning in place. Rotate exposed credentials only after persistence paths and revocation watchers are removed, because the attacker can use token revocation as a trigger.

Key takeaways

• This incident shows that trusted publishing identities can be turned into a worm delivery mechanism even when package provenance remains valid.
• The scale matters because 11 malicious releases spread across 61 packages and hundreds more republished within hours, which is enough to overwhelm manual triage.
• The control that would have changed the outcome is governance over repository-open execution, maintainer lifecycle, and secret segregation, not only install-script blocking.

Key terms

• Repository-open execution risk: The condition where simply opening a repository can trigger code, scripts, or agent actions without a package install. It matters because editor settings, workspace files, and AI assistant configuration can become execution surfaces that bypass traditional dependency controls.
• Publishing Identity: The account, token, or credential set that authorises changes to a software package distribution channel. It is a privileged non-human identity because it can affect many downstream systems at once, so compromise of this identity can become an ecosystem-wide security event.
• AI tool credential segregation: The practice of separating AI assistant tokens and configuration from cloud, registry, and developer credentials. This reduces blast radius when a workstation or repository is compromised because the attacker cannot move from one token class to another without crossing explicit control boundaries.
• Provenance without trust: A state where an artifact is correctly signed or attested, but the identity behind the build or release process is no longer trustworthy. The artefact may verify cleanly while the release pipeline itself has already been compromised, which means provenance checks must be paired with identity governance.

What's in the full article

Cycode's full analysis covers the operational detail this post intentionally leaves for the source:

• A minute-by-minute campaign timeline that helps responders validate where the compromise began and how quickly it propagated.
• The full affected-version list and rollback targets for each package family, which teams need for containment and change control.
• The kill-switch and persistence removal sequence that matters before any credential rotation begins.
• The detector and triage signals used to distinguish repository-open compromise from ordinary dependency updates.

👉 Cycode’s full post covers the attack chain, affected versions, and containment sequence in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.