AI agents and IDE hooks expand the software supply chain attack surface

At a glance

What this is: This analysis shows how the Shai-Hulud worm shifted from npm lifecycle scripts into IDE and AI-agent hooks to execute through trusted developer tooling.

Why it matters: It matters because IAM and security teams must now treat AI agents, IDE configuration, and developer workstations as part of the identity and access attack surface, not just package registries.

By the numbers:

• The latest Shai-Hulud campaign affected more than 800 npm packages representing roughly 2 billion monthly package downloads.
• The latest Shai-Hulud campaign affected more than 800 npm packages representing roughly 2 billion monthly package downloads.

👉 Read Backslash Security's analysis of Shai-Hulud's AI agent and IDE hook campaign

Context

Shai-Hulud’s latest wave shows a familiar supply-chain pattern taking a new route. When package install paths become harder to abuse, attackers move execution into trusted tooling, configuration files, and developer workflows, which creates a broader software supply chain attack surface that includes AI agents and IDEs.

That matters to identity and access governance because the malicious code is not just using software distribution. It is exploiting trusted execution contexts inside developer environments, including repository hooks, AI coding sessions, cloud credentials, and other secrets that identity teams already struggle to inventory and control.

Key questions

Q: What breaks when AI coding agents are allowed to run Git operations on untrusted repositories?

A: The trust boundary breaks because the agent can trigger repository-local behaviour that was never meant to be safe by default. Malicious hooks, nested repositories, and injected instructions can turn a normal checkout into host-level code execution. That risk is highest when the workstation already contains tokens, source code, or internal access.

Q: Why do AI agents and IDEs change the secret-management problem?

A: Because they operate inside the same environment as developer credentials, cloud tokens, and source-control access. When attackers compromise those tools, they can harvest secrets from local files and configuration directories rather than attacking a central vault. That expands the identity boundary into the workstation and toolchain.

Q: What do security teams get wrong about package provenance and trusted publishing?

A: They often assume provenance replaces older authentication paths automatically. It does not. If a legacy token, secret, or key remains valid, the attacker can use that path even when provenance controls exist. The control failure is leaving old and new trust models active at the same time.

Q: How should organisations respond when a supply-chain worm reaches AI tooling?

A: Containment should include repository-wide scans, workspace rebuilds, credential revocation, and review of AI agent directories and hook files. If the malware can trigger from configuration, then cleanup must happen across code, developer machines, and identity systems before access is restored.

Technical breakdown

Hook-based execution in IDE and AI-agent workflows

The worm no longer depends only on npm install time execution. It modifies repository configuration so that opening a project in VS Code or starting a Claude Code session triggers local bootstrap code automatically. That turns trusted developer workflows into execution paths and makes the repository itself the delivery mechanism. The attack works because many teams treat configuration files as operational scaffolding rather than code with security impact, even though those files can launch commands, access local files, and reach secrets stored on the workstation.

Practical implication: treat IDE and AI-agent configuration files as executable attack surface and review them with the same controls used for application code.

Credential harvesting across developer and AI tooling

After execution, the malware enumerates a wide range of secret stores and local paths, including cloud credentials, Kubernetes configs, SSH keys, GitHub tokens, npm credentials, and AI tool directories such as .claude, .codex, and .cursor. That is the key identity lesson in this campaign: AI tooling is both a runtime platform and a secrets reservoir. Once local developer trust is compromised, the worm can harvest credentials that unlock source control, cloud control planes, CI systems, and AI services.

Practical implication: build inventory and detection around secret locations used by developer tools, not just around central vaults and production workloads.

Why provenance did not stop the worm

npm Trusted Publishing and lifecycle-script restrictions reduce one class of abuse, but they do not prove that source code, repository hooks, or downstream configuration were safe. Provenance can attest that a package was built and published through a trusted workflow. It cannot guarantee that the repository content entering that workflow was free from malicious hooks or that later branch changes were clean. That distinction matters because many security models confuse trusted publishing with trusted content.

Practical implication: pair provenance controls with branch scanning, CODEOWNERS review, and change detection for configuration-only pull requests.

Threat narrative

Attacker objective: The attacker wants durable access to developer secrets, broader package propagation, and compromise of CI, source control, cloud, and AI service credentials.

1. Entry occurs when malicious repository changes land in configuration files that developers trust, especially IDE tasks and AI-agent session hooks.
2. Credential access follows when the worm runs inside the local developer environment and searches for cloud tokens, SSH keys, GitHub credentials, npm secrets, and AI service keys.
3. Escalation and propagation happen when stolen GitHub permissions or npm credentials are used to inject workflows, republish compromised packages, and spread the campaign across reachable branches and downstream consumers.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.

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

NHI Mgmt Group analysis

AI agent hooks have become a software supply chain control point, not just a developer convenience. This campaign shows that local agent and IDE hooks can trigger code execution even after package-install vectors are reduced. That changes the governance problem from package hygiene to runtime trust in developer workflows. The practical conclusion is that AI tooling configuration belongs in the same control plane as source code and CI policy.

Secret exposure now extends into the AI toolchain boundary. The presence of .claude, .codex, and .cursor paths in the collector confirms that attackers already understand where developer and agent secrets live. This is a non-human identity issue as much as a supply-chain issue because API keys, tokens, and service credentials are the identities being stolen and reused. Practitioners should treat AI agent environments as credential-bearing assets with lifecycle controls.

Trusted publishing is not equivalent to trusted content. Provenance can tell you that a workflow signed and released a package, but it does not tell you whether the repository content was safe when it entered the pipeline. That is a governance assumption gap, not a tooling gap. Teams need controls that verify configuration integrity, branch state, and downstream execution paths, not provenance alone.

Developer configuration has crossed into production-risk territory. The worm spreads through files that many organisations still treat as local convenience settings. Once those files can execute commands, load setup scripts, and reach secrets, they become part of the production attack surface. The named concept here is configuration-as-code trust drift, which describes the point where informal developer settings become attacker-controlled runtime logic. The practical response is to govern those files with the same change, review, and scanning discipline as application code.

Branch-wide propagation changes the containment model. If malicious hooks can be pushed into multiple reachable branches, remediation that focuses only on main is incomplete. This widens the blast radius and makes branch inventory, pull request review, and workspace rebuilds central to recovery. Practitioners should align containment with repository topology rather than a single protected branch.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• Forward look: Read OWASP NHI Top 10 to map these hook-and-secret abuse patterns to agentic application risk controls.

What this signals

Configuration drift is now an identity-risk amplifier. As developer tooling absorbs more AI agent behaviour, the boundary between code, credentials, and runtime execution becomes harder to define. Teams should expect more threats that begin in repository files but end in credential theft, workload access, or fraudulent automation. The operational answer is to tie repository governance to identity governance and secret lifecycle controls.

The practical signal for practitioners is that AI tooling inventories matter as much as dependency inventories. Without visibility into where agents run, what files they can read, and which secrets they can reach, response teams will keep missing the true persistence layer. For broader context on agentic risk, see the OWASP NHI Top 10.

For practitioners

• Audit AI-agent and IDE hook files Review .vscode/tasks.json, .vscode/setup.mjs, .claude/settings.json, .claude/setup.mjs, and related repository configuration across all branches for unexpected execution paths.
• Rebuild developer environments from trusted images Do not rely on file deletion alone. Rebuild compromised workstations, build machines, and CI runners from known-good images so residual hooks, scheduled tasks, and cached secrets are removed.
• Rotate every exposed secret immediately Assume cloud credentials, GitHub tokens, SSH keys, npm tokens, and AI service credentials have been compromised, then revoke and replace them before re-enabling developer access.
• Treat repository config as code Protect .github/workflows, .vscode, and .claude directories with CODEOWNERS, mandatory review, and branch protection so configuration-only pull requests cannot execute unreviewed changes.
• Inventory AI tooling and secret locations Maintain an inventory of AI agents, MCP servers, and developer tools, then map the local paths and secret stores each tool can access for detection and response coverage.

Key takeaways

• Shai-Hulud shows that supply-chain malware can pivot into IDE and AI-agent hooks, making developer tooling part of the attack surface.
• The campaign’s reach across more than 800 packages and roughly 2 billion monthly downloads shows how quickly repository-level compromise can scale.
• Teams need to govern configuration files, developer workstations, and AI tool secrets with the same discipline applied to code and production credentials.

Key terms

• Hook-based execution: A technique where code runs automatically through configuration or event triggers rather than direct user launch. In developer environments, hooks in IDEs, AI tools, or repository settings can turn trusted workflows into hidden execution paths for malware.
• Configuration-as-code trust drift: The gradual shift from treating configuration files as convenience settings to treating them as executable logic with security impact. Once repository and tool configuration can launch commands, they require the same governance, review, and detection as application code.
• AI toolchain secrets: Credentials, tokens, and API keys stored in or accessible from AI coding tools, agent runtimes, and related developer directories. These secrets can expose cloud, source control, and model services, so they must be inventoried and rotated like any other privileged identity material.
• Trusted Publishing: Trusted publishing is a release method that ties package publication to a verified CI workflow, usually with short-lived identity tokens and provenance evidence. It reduces the value of stolen legacy credentials, but only if older publish paths are fully removed and not left alongside the new flow.

What's in the full article

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

• File-by-file examples of the malicious IDE and Claude Code hooks used to trigger execution.
• The specific credential locations and secret types the collector searched across developer environments.
• Repository and branch remediation steps that go beyond deleting infected files.
• The malware behaviours that complicate incident response and credential revocation.

👉 Backslash Security's full post covers the hook-based execution chain, credential theft paths, and containment steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and agentic AI identity. It helps practitioners connect identity controls to the broader security lifecycle that this kind of attack exploits.