AI agents amplify npm supply chain risk through runtime dependency use

At a glance

What this is: This is an analysis of npm supply chain compromise showing that AI coding agents can ingest poisoned dependencies at runtime and inherit the blast radius of malicious package updates.

Why it matters: It matters because IAM, secrets, and workload governance all assume reviewable, stable dependency use, but AI agents and automated pipelines can collapse that assumption in seconds.

👉 Read Oligo Security's analysis of npm supply chain attacks and AI agent exposure

Context

AI agent supply chain risk is the failure mode where a system that automatically installs, resolves, or executes dependencies can inherit a malicious package before any human reviews the change. In this incident, the problem was not just poisoned open-source code. It was the assumption that declared dependencies and runtime behaviour will stay aligned.

For IAM and NHI programmes, the relevant question is who or what is allowed to fetch code, use secrets, and write back into repositories without a human approval step. That matters for service accounts, CI/CD identities, and autonomous coding agents alike, because each can turn a package compromise into credential exposure and downstream persistence.

The starting position in many enterprises is typical rather than exceptional: dependency trust is still inferred from manifests, repositories, or package ranges. The article shows why that model is no longer enough once AI agents participate in software delivery.

Key questions

Q: What breaks when AI coding agents automatically install poisoned npm packages?

A: The break point is the human review window. When an agent resolves and installs dependencies on its own, a malicious package can execute before anyone checks the version, the maintainer, or the code path. That turns package trust into a runtime governance issue and increases the chance that secrets, tokens, and workflow permissions are exposed during normal delivery.

Q: Why do automated build identities increase supply chain compromise risk?

A: Automated build identities often have access to package registries, repositories, and secrets that were granted for delivery efficiency, not for adversarial resilience. When one of those identities is compromised through a poisoned dependency, attackers can move from execution to credential theft and workflow persistence without needing a second exploit.

Q: How do security teams know whether a dependency risk is real or only declared?

A: They need runtime evidence. A declared dependency range may look benign, but the only reliable signal is what was installed and executed in live environments. If runtime telemetry shows a compromised version or unexpected repository activity, the risk is real even if the manifest still appears unchanged.

Q: Should organisations treat AI coding agents like privileged software identities?

A: Yes. If an AI agent can install code, access secrets, or modify repositories, it is functionally acting as a privileged non-human identity and should be governed that way. That means task-scoped access, explicit boundaries, and monitoring of its downstream actions, especially when it can touch build and release systems.

Technical breakdown

How npm dependency resolution becomes a runtime trust problem

Modern JavaScript dependency handling allows loose version ranges, which means a declared package such as a major version constraint can resolve to a newly published minor or patch release without any change to the application code. That is convenient for delivery velocity, but it also creates a moving target for security review. If a maintainer account is compromised, poisoned releases can inherit trust from the package name and version semantics alone. The important detail is that the malicious code is not forced through an exploit chain. It arrives through normal installation and executes as part of standard application flow.

Practical implication: validate what is actually installed and executed, not only what is declared in manifests.

Why AI coding agents inherit supply chain exposure faster than humans

AI coding agents that resolve dependencies automatically compress the time between publication and execution. A human developer may review a pull request, notice a suspicious update, or delay installation. An agent may fetch, install, and use the package as soon as the resolver finds it. That changes the threat model from one of delayed human-mediated adoption to immediate machine-mediated adoption. The control issue is not intelligence. It is runtime autonomy in the software delivery path, which removes the review window that traditional AppSec and IAM assumptions rely on.

Practical implication: treat agent-driven dependency resolution as a privileged execution path requiring explicit governance.

CI/CD credential abuse and workflow persistence through poisoned packages

Once malicious code runs inside a build or developer environment, it can search for tokens, GitHub credentials, and cloud secrets, then abuse those credentials to write workflows, republish packages, or exfiltrate results to attacker infrastructure. That creates persistence beyond a single compromised workstation because repository-level actions can propagate into future builds and downstream consumers. The attack is effective because it blends package compromise with identity abuse. The package is only the entry point. The real leverage comes from secrets already available to the build identity and from automation that accepts those actions as normal.

Practical implication: segregate build credentials, limit write access, and monitor repository actions as identity events.

Threat narrative

Attacker objective: The attacker objective was to turn trusted package publishing into a reusable channel for credential theft, workflow persistence, and downstream supply chain compromise.

1. Entry occurred through phishing against a maintainer account using a fake npm support domain, which gave attackers legitimate publishing access.
2. Credential access followed when the trojanized package searched for tokens, cloud credentials, and GitHub credentials, then validated and abused any it found.
3. Impact came from automated repackaging, workflow planting, and exfiltration, which extended compromise across downstream packages and CI environments.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.

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

NHI Mgmt Group analysis

Runtime dependency trust is a governance assumption, not a technical guarantee: Declared package ranges were designed for human-reviewed release cycles and stable publishing pipelines. That assumption fails when an AI agent or automated build system resolves and installs new code immediately after publication. The implication is that dependency trust has become an execution-time governance problem, not a manifest-review problem.

Credential exposure inside build systems is the real blast radius multiplier: The compromise did not stop at malicious code execution. It escalated into token hunting, cloud credential abuse, and repository workflow manipulation, which turns a package issue into an identity issue. OWASP-NHI and ZT-NIST-207 both matter here because the build identity itself becomes the attack surface.

Runtime visibility is now the source of truth for software delivery identity: Static SBOMs and dependency scanners can tell you what should be present, but not what actually executed. That leaves a blind spot whenever automation installs, loads, or republishes packages on its own. Practitioners should treat runtime execution as the only defensible evidence of package trust.

AI agents are forcing a crossover between NHI governance and software supply chain security: A coding agent that resolves dependencies and acts on those results is no longer just a developer tool. It behaves like a non-human identity with delegated access to code, secrets, and repositories. That means the same governance questions used for service accounts now apply to agent-driven software delivery.

Package compromise becomes identity persistence when workflow write access is available: The attacker did not need a new exploit path once inside. Access to repository workflows and package publishing was enough to create durable footholds and broaden impact across future builds. For practitioners, the governance failure is unbounded write capability tied to an identity that was never meant to persist beyond a task.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• The governance lesson carries forward into Top 10 NHI Issues, where credential sprawl and weak lifecycle control remain recurring failure modes.

What this signals

Runtime dependency trust debt: organisations that rely on manifests, SBOMs, and static scans are carrying unresolved exposure whenever autonomous tooling can install code faster than humans can review it. The practical shift is toward observing execution, not just declaration, and aligning that with identity controls for build agents and CI service accounts.

The broader signal is that software supply chain security is now inseparable from NHI governance. Once a build identity can fetch, execute, and republish code, the organisation has created a non-human path to privilege and persistence that deserves the same scrutiny as any other high-risk credential path.

Teams should expect more attacks that combine maintainer compromise, poisoned packages, and secrets harvesting because the economics are favourable and the review window is shrinking. That makes repository write access, secret scope, and runtime telemetry the controls that need board-level attention, not just dependency counts.

For practitioners

• Inventory every identity that can install or republish dependencies Map developer accounts, CI/CD service accounts, bots, and AI coding agents that can resolve packages, write workflows, or publish artifacts. Separate read-only build consumers from identities with write access to repositories and package registries.
• Require runtime verification for executed dependencies Use runtime controls to observe what is actually installed, loaded, and executed in build and production environments. Treat package manifests as input, not proof, when agentic or automated systems can act before review.
• Restrict secrets available to build and agent identities Remove long-lived tokens, broad cloud credentials, and repository write permissions from identities that only need task-scoped access. Apply separate controls for package installation, workflow modification, and release publishing.
• Alert on repository workflow creation from non-human actors Detect when build identities, bots, or agents create GitHub Actions workflows, modify release automation, or republish packages. Those actions often indicate that a compromised dependency has moved from execution into persistence.

Key takeaways

• The core risk is not just malicious npm code, but the trust model that lets automated systems execute it before review.
• The incident shows how package compromise rapidly becomes credential theft and workflow persistence once build identities are over-privileged.
• Runtime visibility and task-scoped access are the controls most likely to limit impact when AI agents or CI systems ingest poisoned dependencies.

Key terms

• Runtime dependency trust: The assumption that a package or library is safe because it was declared in a manifest or resolved from a trusted registry. In practice, trust must be validated at execution time because version ranges, compromised maintainers, and automated resolvers can turn a benign dependency into a live security event.
• Build identity: A non-human identity used by CI/CD systems, bots, or automated agents to fetch code, install dependencies, publish artifacts, or modify repositories. It often has broader access than the task requires, which makes it a high-value target when supply chain compromise can pivot into secrets abuse or persistence.
• Runtime visibility: Observability into what software actually installs, loads, and executes in a live environment. It closes the gap between declared configuration and executed behaviour, which is critical when malicious updates can enter through normal delivery paths and evade static review.
• Package trojanisation: The act of inserting malicious logic into a software package so that normal installation or import triggers attacker-controlled behaviour. In supply chain attacks, trojanised packages often inherit user trust from a legitimate name while performing credential theft, data manipulation, or persistence once executed.

Deepen your knowledge

Dependency trust and runtime verification are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are governing build identities, CI agents, or AI coding tools, it is worth exploring.

This post draws on content published by Oligo Security: The Hidden Risks of the NPM Supply Chain Attacks: AI Agents. Read the original.