Supply-chain worm blast radius is an identity question

At a glance

What this is: This is an NHI-focused analysis of how supply-chain worms like Shai-Hulud change incident scoping from package inventory to credential and identity blast radius.

Why it matters: It matters because IAM, PAM, and NHI teams need to know which secrets, service accounts, and AI credentials were exposed, what they could reach, and who can revoke them quickly.

By the numbers:

• On the morning of August 4, 2026, a self-replicating worm compromised over 400 npm packages in hours.
• Keyv alone reaches 600 million monthly downloads, showing how quickly a single poisoned dependency can amplify exposure.
• In most enterprises, non-human identities outnumber human identities by 10 to 50 times.
• The August 2026 variant targeted AI credentials alongside AWS, Azure, and GCP secrets.

👉 Read Oasis Security's analysis of Shai-Hulud blast radius and NHI exposure

Context

Supply-chain worms expose a familiar governance blind spot: organisations often know which packages were installed, but not which non-human identities and secrets those packages could reach. In this case, blast radius is not a software inventory question first. It is an identity question, because the attacker’s value comes from npm tokens, cloud workload credentials, service account keys, and AI API keys.

That shift matters for NHI governance, IAM, and incident response alike. If a poisoned dependency can execute inside CI/CD, the programme must answer which machine identities were present, whether they were actually exposed, whether they were used, and what each one could do before and after compromise.

The article’s starting position is typical for modern software delivery: packages are assumed to be the unit of risk, while credentials are treated as secondary artefacts. Shai-Hulud shows that assumption is backwards when software supply-chain activity collides with unmanaged NHIs.

Key questions

Q: What should teams do first when a supply-chain worm may have exposed secrets?

A: Start with the credential estate, not the package list. Identify every exposed or potentially exposed NHI secret in build systems, developer endpoints, and connected cloud services, then rank them by privilege and active use. That gives incident responders a containment sequence that matches the real attack surface instead of the software inventory.

Q: Why do cloud and NHI secrets make supply chain attacks more dangerous?

A: Because a single stolen token can open access to multiple environments, including cloud consoles, CI systems, and infrastructure tools. NHI secrets often have broader reach than a human session and may remain valid long after the initial compromise. That turns one infected workstation into a pivot point for wider account abuse.

Q: How do security teams know whether blast-radius controls are working?

A: Blast-radius controls are working when a compromised identity can no longer reach systems outside its normal operational purpose. Look for blocked anomalous sources, denied protocol use, and reduced lateral movement options. If a stolen credential still behaves like a universal pass key, the control model is not actually containing risk.

Q: What is the difference between package compromise and identity compromise in a supply-chain worm?

A: Package compromise tells you where malicious code landed. Identity compromise tells you which secrets were exposed, what they could access, and whether they were used after theft. In modern supply-chain attacks, the latter determines real blast radius because credentials, not packages, open the downstream systems.

Technical breakdown

Why supply-chain worms target non-human identities first

Shai-Hulud is designed to harvest secrets after a poisoned package is installed. The worm scans for npm tokens, GitHub PATs, cloud credentials, SSH keys, and AI API keys, then uses those credentials to republish itself and expand its reach. That means the technical payload is not just code execution. It is credential discovery, credential reuse, and propagation through trusted build and publishing workflows. Because CI/CD often executes package install steps automatically, the worm can reach high-value NHIs without needing interactive access. The real mechanism is stolen trust, not malware persistence in the traditional sense.

Practical implication: incident teams need a credential-focused containment path for build environments, not only a package removal workflow.

How blast radius becomes an identity graph problem

A package list only shows where the worm may have run. It does not show which identities were present, what secrets were exposed, whether those secrets were used, or what permissions they carried. To calculate blast radius, teams have to map candidate NHIs, confirm exposure, check active telemetry, and rank access by privilege. That is an identity graph exercise. The most dangerous items are exposed, high-privilege, unrotated credentials with live dependencies. In practice, this is the difference between a broad theoretical compromise and a prioritized list of revocation actions that can be executed safely.

Practical implication: build scoping should pivot from package inventory to identity inventory, entitlement mapping, and usage telemetry.

Why AI API keys now belong in the NHI response plan

The article shows a category shift. The worm no longer stops at cloud and developer credentials. It also targets AI service keys because those keys now carry spend, data access, and operational reach. As organisations wire AI agents and automated workflows into delivery stacks, they add another class of NHIs whose exposure can be harvested in the same intrusion path. This is not a niche AI problem. It is the extension of NHI governance into the AI control plane, where a stolen key may unlock both model usage and downstream data movement.

Practical implication: AI service credentials should be included in the same exposure, rotation, and ownership controls as cloud and build-system secrets.

Threat narrative

Attacker objective: The attacker wants to steal reusable credentials that let the worm propagate, deepen access, and widen the supply-chain blast radius.

1. Entry begins when a poisoned npm package is installed in CI/CD or on a developer workstation, giving the worm execution inside trusted software workflows.
2. Escalation follows when the worm scans local environments for npm tokens, cloud credentials, GitHub PATs, SSH keys, and AI API keys, then reuses those secrets to expand access.
3. Impact occurs when stolen credentials are used to republish malicious packages, reach cloud and SaaS resources, and extend compromise across the software supply chain.

Breaches seen in the wild

• Hard-Coded Secrets in VSCode Extensions — 500+ VSCode extensions expose hardcoded tokens and credentials creating massive developer supply chain risk.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Blast radius in a supply-chain worm is an identity question, not a package question. Packages tell you where code executed. They do not tell you which non-human identities were exposed, which secrets were harvested, or what those credentials could reach. The operational mistake is treating software inventory as a proxy for exposure. Practitioners should reframe incident scoping around identity reach rather than dependency count.

Credential harvest is the core failure mode, and it is amplified by standing NHI trust. npm tokens, cloud workload identities, GitHub PATs, and AI API keys all behave as reusable machine credentials, which makes them valuable propagation material. Once one secret is captured, the attacker can seed additional compromise through trusted publishing and build channels. The implication is that NHI governance must treat reusable credentials as part of the attack surface, not as incidental support assets.

Identity blast radius is a named control concept teams should adopt. It is the combined measure of exposure, privilege, ownership, and active use for every machine credential in the chain. That concept matters because a dormant low-privilege token is not equivalent to an admin-scoped service principal or an unrotated build secret. Security programmes that cannot rank identity blast radius cannot triage supply-chain incidents at the speed these worms now demand.

AI API keys now belong in the same governance model as cloud and DevOps secrets. The article shows that attackers already treat AI credentials as harvestable NHIs because they unlock spend and downstream data access. That collapses any separation between software supply-chain defence and AI governance. Practitioners should stop managing AI keys as a special case and fold them into standard NHI lifecycle, ownership, and revocation controls.

Shai-Hulud validates a broader NHI governance failure: many organisations still cannot answer who owns a machine credential before a breach. Ownership mapping is what turns revocation from a forensic exercise into an operational one. When every secret has a named owner and a known dependency set, blast radius becomes measurable. Without that, the response becomes a scramble across build systems, SaaS, and cloud accounts.

From our research:

• In most enterprises, non-human identities outnumber human identities by 10 to 50 times, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• That gap makes Ultimate Guide to NHIs the natural next reference for mapping ownership, lifecycle, and blast radius across machine credentials.

What this signals

Identity blast radius is becoming the practical unit of incident response for supply-chain compromise. When package execution happens inside CI/CD, the decisive question is which credentials were present, not which dependency tree was touched. Teams that cannot map exposure to ownership and entitlement will continue to overestimate software risk and underestimate identity risk.

AI service credentials should be treated as first-class NHIs, not edge cases. As AI usage spreads through build and delivery workflows, the same harvest-and-propagate pattern now applies to model API keys, cloud secrets, and publishing tokens. The governance implication is simple: if a secret can be reused by software, it belongs in the NHI programme.

With 85% of organisations lacking full visibility into third-party vendors connected via OAuth apps, per The State of Non-Human Identity Security, supply-chain response cannot stop at internal systems. Build-time identity dependencies now extend into external ecosystems, so scoping has to include connected SaaS, partner access, and delegated tokens.

For practitioners

• Inventory the credential estate behind every build path Enumerate npm tokens, GitHub PATs, cloud workload identities, SSH keys, and AI API keys present in CI/CD and developer environments before you assess package impact.
• Rank identities by exposure, privilege, and live use Prioritise secrets that were flagged as leaked, carry broad entitlement, or have recent authentication activity during the compromise window.
• Revoke and rotate with dependency awareness Rotate exposed credentials in a dependency-aware sequence so that publishing, deployment, and service dependencies are not broken during containment.
• Put AI service keys under NHI lifecycle control Include AI API keys in the same ownership, rotation, and revocation workflows used for cloud and DevOps secrets, especially where automated workflows can access them.
• Add package-publishing MFA and ownership mapping Require MFA for package publishing tokens and ensure every high-privilege NHI has a named owner who can approve revocation and remediation.

Key takeaways

• Supply-chain worms now weaponise identity, because stolen machine credentials create the real blast radius.
• Package inventories describe execution sites, but identity inventories describe impact, reach, and revocation priority.
• AI API keys, cloud credentials, and publishing tokens need the same lifecycle governance, ownership, and rotation discipline.

Key terms

• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Standing Credential: A standing credential is any secret that remains usable until it is manually rotated or revoked. In NHI governance, it creates durable access that can be stolen, replayed, or propagated from trusted tooling unless runtime boundaries and expiry are built in.
• Credential Harvesting: Credential harvesting is the collection of secrets, tokens, keys, or certificates from a compromised workload. In container environments, it often targets file paths, environment variables, service account tokens, and metadata services because those locations frequently hold reusable identity material.
• NHI Ownership Transfer: NHI ownership transfer is the reassignment of a non-human identity from one employee to another during a change event such as offboarding. It is used when the credential still supports a live business process and cannot simply be revoked. Effective transfer requires context, dependency mapping, and governance approval.

What's in the full article

Oasis Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step 7-step blast radius method for ranking compromised identities after a worm event
• Detailed examples of how to map exposed secrets to live usage and privilege scope
• Operational guidance for safe rotation without breaking dependent workloads
• Platform-specific workflow for inventorying cloud, SaaS, PaaS, and on-premises NHIs

👉 The full Oasis Security post covers the 7-step scoping method, identity ranking logic, and rotation workflow details.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.