s1ngularity shows how npm supply chain attacks reach AI tools

At a glance

What this is: This is a supply chain attack analysis showing how malicious Nx packages stole developer secrets and used AI tools to move those secrets into public GitHub repositories.

Why it matters: It matters because developer endpoints, AI tooling, and CI/CD identities now sit on the path from package compromise to cloud account takeover, which requires broader NHI and IAM controls.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• Only 44% of developers are reported to follow security best practices for secrets management.

👉 Read Orca Security's analysis of the s1ngularity supply chain attack

Context

Nx became the delivery vehicle for a supply chain attack that moved from a malicious npm install to developer secret theft and public repository exposure. The primary security issue is not just package integrity, but the identity trust chain behind developer machines, AI tools, and CI/CD access.

For IAM and NHI teams, the important shift is that source-code compromise now intersects with secret handling and tool permissions on the endpoint. When AI developer tooling is configured with broad permissions, the package manager is no longer the only boundary that matters.

Key questions

Q: How should security teams handle exposed developer secrets after a supply chain attack?

A: They should assume the secrets are reusable until proven otherwise, revoke them immediately, and trace where they were accepted before the compromise was contained. Developer tokens and keys often bridge source control, build systems, and cloud accounts, so response has to cover all three layers, not just the endpoint.

Q: Why do malicious npm packages create more risk than ordinary code defects?

A: A malicious package can execute in a trusted installation path and act with the privileges of the developer session, which makes it an identity compromise as much as a software one. The risk increases when the package can read local secrets, modify shell profiles, or interact with authenticated tools.

Q: What do organisations get wrong about AI developer tools and secret theft?

A: They often treat AI assistants as productivity tools instead of access-bearing systems. If the tool can read code, inspect files, or run with broad permissions, it can also become a channel for secret extraction or exfiltration when those permissions are abused.

Q: What should teams do before a compromised developer workstation reaches cloud systems?

A: They should isolate the endpoint, revoke any visible secrets, inspect shell persistence, and audit source-control activity for unauthorized repository creation or uploads. The key is to stop the workstation from becoming a bridge into build pipelines and cloud identities.

Technical breakdown

Malicious npm post-install scripts as an identity compromise path

The attack used post-install scripts in multiple Nx package versions to run automatically on developer machines. That matters because package installation is already a trusted execution moment, so the script could enumerate secrets, inspect endpoints, and collect credentials without needing a separate exploit chain. In practice, this turns dependency trust into identity compromise, because the compromised package can act with the privileges of the developer session, local shell, and any authenticated tools already present.

Practical implication: Treat package installs as privileged execution events and monitor for script-based credential harvesting during dependency updates.

AI developer tools as an exfiltration channel

The attackers specifically looked for installed LLM tools and then abused permissive flags such as --dangerously-skip-permissions, --yolo, and --trust-all-tools. Those settings weaken the guardrails that normally constrain tool use, allowing the attacker to move stolen data through AI workflows instead of only through standard file or network channels. This is an important extension of supply chain risk because the threat is no longer only code execution, but tool-mediated data extraction from the development environment.

Practical implication: Restrict AI tool permissions on developer endpoints and log when assistants are allowed to bypass safety and access controls.

Secret exposure becomes cloud compromise when tokens and keys are reusable

The stolen material included GitHub tokens, SSH keys, npm credentials, and crypto wallets, which are all high-value non-human identities or credentials. Once those secrets leave the endpoint, they can often be replayed against source control, build systems, and cloud platforms with little friction. That is why this incident is best understood as a machine-identity and access-path problem, not only as malware in a package registry.

Practical implication: Assume any exposed developer secret is reusable until proven otherwise and build rapid revocation into your response workflow.

Threat narrative

Attacker objective: The attacker objective was to steal reusable developer secrets and turn package trust into broad access to source control, cloud, and financial assets.

1. Entry occurred when attackers published malicious Nx package versions to npm and triggered the post-install script on developer machines.
2. Credential access happened as the script enumerated local environments and harvested GitHub tokens, SSH keys, npm credentials, and wallet material.
3. Impact followed when stolen data was pushed into public GitHub repositories, creating immediate exposure and likely enabling further account abuse.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Package trust is now identity trust. The s1ngularity attack shows that dependency compromise is no longer a software-only problem. Once a malicious package can execute in a developer session, it can harvest the same secrets, tokens, and authenticated paths that IAM teams assume belong to a trusted user context. The practitioner conclusion is straightforward: package integrity and identity governance now overlap.

AI developer tooling creates a new exfiltration layer. The attackers did not just steal secrets, they looked for LLM tools and used permissive execution flags to move data out through those tools. That makes the developer workstation a governance boundary for both human and machine identity, because the AI assistant can become a credential relay if permissions are too broad. Practitioners need to evaluate AI tool policy as part of access control, not as a separate productivity concern.

Secret sprawl is the real blast-radius amplifier. GitHub tokens, SSH keys, npm credentials, and wallet material all behaved as reusable bearer assets once extracted. That means the compromise did not depend on breaking cryptography, only on finding enough live secrets to pivot into other systems. Ephemeral credential trust debt: the environment assumed secrets would remain local and short-lived, but the attack showed they were neither. Practitioners must treat every endpoint secret as a potential lateral movement token.

Developer endpoints belong in the NHI control plane. The incident started on machines many organisations still treat as productivity devices, then expanded into CI/CD and cloud exposure. That is a governance failure, not just a detection gap. The broader identity programme has to recognize that developer workstations, build pipelines, and AI assistants are all part of the non-human access surface that can turn a package event into an enterprise compromise.

Runtime constraints failed because the attacker worked inside trusted workflows. The package manager, shell environment, and AI toolchain all executed within normal user expectations, which is exactly why the attack spread quickly. Controls that only watch for external intrusion miss this class of abuse. The practitioner conclusion is to govern trusted execution paths with the same seriousness as perimeter entry.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• The same research notes that DeepSeek accidentally embedded over 11,000 secrets in its training data and left a database exposed online, revealing more than one million sensitive records.
• That speed makes the developer pipeline a live identity risk surface, so teams should pair secrets governance with the 52 NHI breaches Report to map real-world failure patterns.

What this signals

Ephemeral credential trust debt: developer environments are now governance boundaries, not just endpoints. When package installs can trigger secret theft and AI tooling can carry those secrets outward, IAM teams need to treat workstation controls, repository permissions, and secret revocation as one control plane. The practical signal is to align your response model with the OWASP Non-Human Identity Top 10, because bearer secrets behave like non-human identities once exposed.

With 44% of developers following secrets-management best practices, the operational gap is already wide before attackers add supply chain compromise into the mix. That means programme owners should expect endpoint-to-cloud blast radius unless they connect developer policy, CI/CD hardening, and secret hygiene into a single review cycle. The right comparison is not tool versus tool, but whether your identity programme can revoke, detect, and contain at machine speed.

Teams should also expect AI-assisted exfiltration to blur the boundary between code security and identity security. The next priority is not only finding vulnerable packages, but identifying where assistants can read local credentials, where tokens can be replayed, and where repository creation can turn into public disclosure. For broader threat modelling, MITRE ATLAS adversarial AI threat matrix is increasingly relevant where AI tools are part of the developer path.

For practitioners

• Harden package-install execution paths Block or alert on post-install scripts from newly published packages, especially in developer environments that reach cloud or source-control systems. Treat dependency updates as executable change events, not simple file downloads.
• Restrict AI tool permissions on developer endpoints Remove permissive flags such as --dangerously-skip-permissions and audit any assistant configuration that can read local files, shells, or tokens without explicit approval. Log assistant access to source code and secret stores.
• Rotate and revoke exposed developer secrets fast Build a response path that revokes GitHub tokens, SSH keys, npm credentials, and any other bearer secrets as soon as endpoint compromise is suspected. Assume reuse across source control, build systems, and cloud accounts until verified otherwise.
• Treat developer endpoints as production assets Monitor workstation activity for unusual repository creation, shell profile modification, and secret harvesting artefacts such as inventory files or injected telemetry scripts. Extend detection to CI/CD contexts because compromised endpoints often become pipeline footholds.

Key takeaways

• Supply chain compromise now reaches the developer identity layer, where local secrets, AI tools, and shell access can all be abused in a single workflow.
• Public exposure of GitHub tokens, SSH keys, and similar bearer assets creates immediate downstream risk because attackers can reuse them across source control, pipelines, and cloud accounts.
• Defenders need to govern developer endpoints as production assets, with rapid revocation, AI tool restrictions, and package-install monitoring all in the same response model.

Key terms

• Developer endpoint as an identity surface: A developer workstation or laptop becomes an identity surface when it stores, uses, or can exfiltrate reusable credentials. In practice, that means local shells, package managers, AI assistants, and browser sessions all participate in access risk, even when no production system is directly targeted.
• Bearer secret: A bearer secret is a credential that grants access to whoever presents it, without needing additional proof of identity. GitHub tokens, SSH keys, API keys, and many session artifacts behave this way, which is why exposure on a developer machine can quickly become broad enterprise access.
• Secret sprawl: Secret sprawl is the uncontrolled spread of credentials across endpoints, pipelines, code, and tools. The more places a secret exists, the more likely it is to be copied, reused, or exposed, and the harder it becomes to revoke trust quickly after compromise.
• Supply chain identity risk: Supply chain identity risk is the possibility that software delivery mechanisms will expose or misuse identities rather than only inject code defects. It includes package scripts, build dependencies, and developer tooling that can harvest or relay credentials outside their intended control path.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Orca Security: s1ngularity supply chain attack analysis. Read the original.