AI agent supply chain attacks expose trust gaps in dependencies

At a glance

What this is: This is an analysis of how AI agent supply chain attacks weaponise trusted npm dependencies, with Shai-Hulud used to show how compromised packages can spread through skills, runners, and downstream builds.

Why it matters: It matters because AI agent skills often inherit broad permissions and deep dependency trees, so identity, token, and dependency governance become part of the same control problem for practitioners.

By the numbers:

• 99.3% ship without a config.json permissions manifest, indicating minimal dependency governance at the ecosystem level.

Context

AI agent supply chain attacks are a governance problem as much as a malware problem. When a skill depends on dozens of npm packages, each update extends trust to maintainers, tokens, and build pipelines that the practitioner does not directly control. The security issue is not only whether code is malicious, but whether the dependency chain can be trusted at install time.

That trust problem becomes sharper when AI agent skills run with file access, shell execution, clipboard access, or network permissions. In practice, the supply chain becomes part of the identity boundary because publishing tokens, maintainer accounts, and package provenance determine which code is allowed to execute inside the agent workflow.

Key questions

Q: What breaks when AI agent dependencies are poisoned?

A: The control that breaks is the assumption that trusted package names imply trusted code. When a dependency is poisoned, the build or install path can execute malicious logic before the skill itself is reviewed, so source-code inspection alone no longer protects the environment. That creates a blind spot in both developer workstations and automated pipelines.

Q: Why do trusted publishing and provenance not fully protect npm packages from supply chain compromise?

A: Trusted publishing proves which workflow created a package, but it does not prove the workflow was safe to run. If an attacker can steer untrusted code into the same release path, the provenance badge can remain valid while the artifact is malicious. Security teams still need workflow hardening, event restrictions, and credential isolation to make provenance meaningful.

Q: What are the signs that tool governance is failing in an AI agent programme?

A: Common signs include broad tool permissions, reusable credentials across unrelated services, approvals happening only after execution, and poor traceability from tool action back to a human principal. If the organisation cannot explain who authorised a consequential call and why, governance is already too weak for the risk level.

Q: Should teams prioritise dependency scanning or permission controls first for AI agents?

A: They should do both, but permission controls usually deserve the first pass because they cap the damage a poisoned package can do. Scanning finds known-bad packages, while permissions define what an installed package can actually reach. If the runtime scope is broad, a clean scan does not remove the blast radius.

Technical breakdown

How dependency hijacking reaches AI agent skills

Dependency hijacking happens when an attacker compromises a trusted package upstream rather than the skill itself. The malicious code then enters the environment through normal install or update behaviour, which is why unpinned versions and automatic updates are dangerous. In AI agent stacks, the impact expands because a single dependency can sit inside a tool-using skill that already has broad filesystem and shell privileges. That makes the supply chain a delivery mechanism for execution, not just a source of software risk. The real failure is that trust is granted before the full dependency tree is inspected. See the AI Coding Agents Security Guide.

Practical implication: Require full dependency-tree review before install, not just top-level code review.

Why long-lived publishing tokens and maintainer accounts are attractive

Package ecosystems concentrate authority in a few identity objects: maintainer accounts, publishing tokens, and registry trust relationships. If those identities are compromised, the attacker can publish malicious versions under a legitimate package name, which is far more effective than creating obviously malicious code from scratch. This is why token lifetime, MFA, and account recovery controls matter in software supply chains. In AI agent ecosystems, the result is especially severe because downstream users often accept package updates automatically and do not inspect every transitive dependency. Identity compromise becomes code compromise. See the AI Agent Identity Security Buyer's Guide.

Practical implication: Treat publishing credentials as high-value identities and reduce their standing privilege.

Why traditional malware scanning misses poisoned dependencies

Traditional scanning often inspects the skill code you can see, but supply chain compromise usually lives one or more layers deeper in the dependency graph. A clean top-level repository can still pull malicious behaviour from a nested package during install, postinstall, or preinstall execution. That is why dependency scanning must be separate from code scanning and behavioural detection. In agentic environments, the distinction matters because the attack surface includes both the agent's own code and the packages that define its tools, permissions, and runtime behaviour. Without tree-level visibility, organisations detect the symptom after the malicious package has already run. See the Shadow AI and AI Agent Discovery Guide.

Practical implication: Scan nested packages continuously and rescan when dependency drift appears.

Threat narrative

Attacker objective: The attacker wants to convert trusted package distribution into a scalable path for stealing credentials, spreading malicious code, and compromising AI agent and developer environments.

1. Entry occurs when attackers compromise a maintainer account or publish a trojanised npm package that downstream skills trust as legitimate.
2. Credential access follows when stolen maintainer tokens, developer credentials, or publishing rights let the attacker update packages at scale.
3. Escalation happens as poisoned dependencies propagate into AI agent skills with broad permissions, giving the payload access to files, shells, and network resources.
4. Impact is the compromise of downstream builds, developer environments, and agent workflows through credential theft, repository abuse, and malicious code execution.

Breaches seen in the wild

• Shai-Hulud npm worm first wave 2025: The first Shai-Hulud wave used stolen npm tokens to trojanise 500+ packages, starting with tinycolor, and leaked developer and CI secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

AI agent supply chain risk is really identity governance for software trust. The article is not only about malicious packages. It is about who can publish, who can update, and which identities a build system is willing to trust without challenge. That makes maintainer accounts, publishing tokens, and dependency provenance part of the identity control plane for agentic systems. Practitioners should treat software supply chain trust as an access governance problem, not a scanning problem.

Named concept: dependency trust inversion. The article describes a pattern where downstream users inherit risk from upstream identities they do not control. Once trust is inverted, a single compromised maintainer or token can affect many skills, runners, and build pipelines at once. That is why agentic systems magnify supply chain exposure more than conventional application stacks. Practitioners should map where trust flows upward and where control is lost.

Broad permissions make poisoned dependencies more dangerous in agentic environments than in ordinary Node.js applications. A skill that can read files, invoke shells, and make network requests gives an attacker a larger operational envelope once dependency code runs. The risk is not theoretical because the article ties package compromise to agent execution contexts that already have meaningful runtime reach. Practitioners should reduce permission scope before they reduce alert volume.

Continuous dependency governance is now a runtime requirement, not a release-time task. The article shows why point-in-time approval fails when packages can change between audits. If updates can arrive through automatic install behaviour, then the governance model must watch for drift after deployment as well as before it. Practitioners should build continuous verification into package and agent lifecycle management.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: AI Coding Agents Security Guide

What this signals

Dependency trust inversion: AI agent supply chains let upstream package identities control downstream execution, so the governance focus has to move from code review to trust provenance, token control, and drift monitoring.

The article shows why runtime controls matter after installation, not just at publish time. Once an agent skill can auto-update dependencies, a clean audit can age out quickly unless teams continuously re-verify the package tree and the permissions attached to it.

For practitioners

• Pin dependency versions and lockfiles Use exact version pinning in package.json and commit package-lock.json so a compromised patch release does not enter automatically.
• Enforce MFA on publishing identities Require multi-factor authentication on npm accounts and reduce the lifetime and scope of publishing tokens used for package release.
• Scan the full dependency tree before install Check nested npm packages against vulnerability data before a skill is installed or updated, not after execution begins.
• Declare and review skill permissions Require a permissions manifest for every skill so reviewers can compare declared access with the runtime privileges the skill requests.
• Rescan on dependency drift Monitor for post-install package changes and trigger rescans whenever a dependency update appears in an audited skill.

Key takeaways

• AI agent supply chain attacks succeed because trusted packages can carry malicious code into skills that already hold broad system permissions.
• The article's evidence shows a single campaign can spread through hundreds of packages and downstream repositories when maintainers or tokens are compromised.
• Teams need continuous dependency verification, scoped publishing identities, and permission manifests to reduce the blast radius of poisoned packages.

Related NHI Mgmt Group resources: AI Coding Agents Security Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · Shai-Hulud npm worm first wave 2025

Key terms

• Dependency Hijacking: Dependency hijacking is a software supply chain attack in which an attacker takes over an abandoned or outdated package and repurposes it with malicious code. Developers may import it as if it were legitimate, which can introduce backdoors, malware, or other hidden compromise into builds and downstream releases.
• Package Publishing Token: A package publishing token is a secret that authorises a person or automation to upload or modify software packages in a registry. If it is stolen or over-scoped, an attacker can inject code, overwrite releases, or propagate malicious updates at scale.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• Permissions Manifest: A permissions manifest is a declaration of what a skill or application is allowed to access at runtime, such as files, network, or shell functions. In agentic environments, it helps compare intended scope with actual privilege so reviewers can spot overreach before a poisoned package runs.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect identity controls to the wider security programme that AI agent supply chains now depend on.