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

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Backslash Security's blog post: Shai-Hulud evolved into a supply-chain worm that uses IDE and AI-agent hooks to keep executing after npm lifecycle scripts were disabled by default.

Why it matters: It matters because developer tooling and local AI environments now sit inside the attack surface, so IAM, NHI, and supply-chain controls must extend to configuration files, tokens, and repo-level trust.

By the numbers:

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

Context

Shai-Hulud’s latest wave shows a common governance gap in software supply chain security: teams often harden package installation while leaving developer tooling and local configuration implicitly trusted. In practice, the execution boundary has moved into IDE hooks, AI-agent session hooks, and repository files that developers open every day.

That creates a genuine identity and NHI angle because the attack is not only about code provenance. It also depends on credentials, tokens, and privileged automation reachable from developer workstations, AI assistants, and repository-level trust decisions. The subject is typical of modern supply-chain abuse: the initial compromise path changes, but the trust model remains too broad.

Key questions

Q: What breaks when repository task files are allowed to auto-execute in developer tools?

A: The main failure is that code review and execution become the same event. A malicious task file can run a downloader or shell command as soon as the project opens, which gives attackers a path into the developer session before any human approval, package inspection, or malware review can intervene.

Q: Why do AI coding agents increase supply-chain risk?

A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment. That widens the blind spot around untracked software and makes package provenance harder to enforce. The practical response is to restrict agent permissions, inventory their workspaces, and review their install behaviour like any other privileged automation.

Q: How should teams detect hook-based malware in repositories?

A: Teams should scan all branches for unexpected editor tasks, agent hooks, workflow changes, and helper scripts that invoke commands outside normal build paths. Detection must cover configuration drift, not only package diffs. If a repository contains execution-capable configuration, it should be treated as a potential persistence mechanism until reviewed.

Q: What should security teams do after a supply-chain worm reaches developer tooling?

A: Containment has to start with rebuilding affected developer and CI environments from trusted images, then rotating every credential the environment could have exposed. Teams should also block unreviewed configuration-only changes and revalidate publishing permissions, because the same attack path can be used to republish infected packages or steal workflow secrets.

Technical breakdown

How IDE hooks become an execution path

The campaign no longer depends only on npm install time. It plants or modifies repository files such as .vscode/tasks.json and related setup scripts so that opening a project in an editor can trigger malicious code automatically. That is a control bypass in the trust boundary between code review and execution. When a repository file can launch a task, the editor becomes part of the runtime, and repository trust becomes execution trust. In practice, this means file-level governance has to treat developer tooling configuration as executable attack surface, not as harmless metadata.

Practical implication: control repository files that can trigger commands with the same rigor as build scripts and application code.

AI-agent hooks turn local assistants into persistence

The malware also abuses AI-agent configuration, including session-start hooks, so the payload runs when a coding assistant begins work in that repository. This is different from traditional package compromise because the trigger sits in the agent’s local operating context, not only in dependency resolution. The result is a hybrid supply-chain and NHI problem: an AI assistant acts as the execution platform, while configuration files provide persistence. That makes agent inventory, local policy enforcement, and hook review critical governance controls, especially where assistants can execute code or access repository state.

Practical implication: inventory AI agents and review their local hook surfaces before allowing them to operate on trusted repositories.

Why credential theft and propagation follow quickly

Once execution begins, the worm searches for cloud credentials, GitHub tokens, SSH keys, npm tokens, and AI service credentials across multiple operating systems. If it finds GitHub permissions, it can inject a malicious workflow that serializes secrets and stores them for later retrieval. If it finds writable npm access, it republishes infected packages to continue spreading. This is classic credential-access plus propagation behaviour, but with a modern twist: the same local developer environment is both the victim and the launchpad. That is why secrets, workflow permissions, and branch coverage all matter together.

Practical implication: treat developer workstations and CI credentials as propagation assets, not just endpoints to clean after compromise.

Threat narrative

Attacker objective: The attacker aims to steal secrets, compromise automation, and keep the worm spreading through both developer tooling and the npm ecosystem.

1. Entry occurs when malicious repository changes place execution logic inside IDE and AI-agent configuration files rather than relying only on npm lifecycle scripts.
2. Credential access follows when the worm searches local systems for cloud credentials, GitHub tokens, SSH keys, npm tokens, and AI service credentials.
3. Escalation and propagation occur when stolen GitHub or npm access is used to steal secrets through workflows or republish infected packages into the ecosystem.
4. Impact is continued supply-chain worm spread, exposed developer and cloud secrets, and compromised automation across reachable repositories and branches.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed 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

Developer tooling is now part of the supply chain trust boundary. The main governance failure is no longer only whether a package was built from trusted provenance. It is whether repository files, editor hooks, and local automation can execute without explicit review. That changes the security model for software teams because configuration becomes runtime. Practitioners should treat developer tooling configuration as controlled code, not as peripheral setup.

AI agents create a new persistence layer for supply-chain malware. The campaign is notable because the agent is not merely reading code, it is participating in execution when hooks fire. That makes agent inventory and local policy enforcement an identity problem as much as a malware problem. NHI governance now has to cover AI assistants that can access repositories, credentials, and workflow contexts. Practitioners should map AI tool permissions before allowing them into production development paths.

Hook-based supply-chain attacks expose a repo-level trust gap. The attack works because teams often review dependency changes more carefully than they review tasks files, session hooks, and branch-wide configuration. That is a named control gap worth calling out: repository trust without execution scoping. The fix is not just better detection, but narrower trust over what configuration may invoke commands. Practitioners should reduce implicit execution rights across every branch.

Secrets exposure and propagation are one control problem, not two. The malware turns developer credentials, GitHub workflows, and package publishing into a single chain. Once one token is compromised, the attacker can exfiltrate secrets, automate propagation, and preserve access across ecosystems. That means credential scope, workflow permissions, and package publishing rights must be governed together. Practitioners should align secrets management with supply-chain controls instead of treating them as separate programmes.

From our research library:

• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• 19% of organisations give AI systems dramatically more access than human employees, nearly one in five granting unrestricted privilege, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Execution has moved from package install to developer context. The practical implication is that supply-chain monitoring now has to cover editor tasks, AI-agent hooks, and branch-level configuration files, not just dependency manifests. Without that scope, malware can keep running after the registry itself has been hardened.

Trust in local AI environments is becoming an identity control problem. When an AI assistant can read repository state and trigger commands, the decisive question is not only whether the model is safe, but whether its execution rights are bounded. Practitioners should align agent permissions with Zero Trust for AI Agents and review any tool that can launch code or access secrets.

Hook-based persistence creates a repository trust gap that conventional package scanning misses. This gap appears when teams inspect dependencies but ignore files that can invoke commands from within the editor or agent session. Security programmes should close that gap by treating configuration, not just code, as a governed execution surface.

For practitioners

• Review execution-capable repository files Inspect .vscode/tasks.json, .claude/settings.json, setup scripts, and similar files on every branch for unexpected command execution or persistence hooks.
• Inventory AI tools and local hooks Build an inventory of AI agents, IDE integrations, and session hooks that can run code or read repository context on developer workstations.
• Rebuild developer and CI environments Restore affected laptops, build machines, and runners from trusted images instead of trying to clean only malicious files after exposure.
• Rotate exposed credentials immediately Assume cloud credentials, GitHub tokens, SSH keys, npm credentials, and AI service secrets reachable from the environment are compromised.
• Protect configuration-only changes with CODEOWNERS Require manual review for repository configuration, workflow files, and branch-wide changes that can execute code or publish packages.

Key takeaways

• The campaign shows that supply-chain malware now uses developer tooling and AI-agent hooks as execution paths, not just package installation.
• The compromise surface includes repository configuration, secrets, and workflow permissions, so cleanup has to extend beyond dependency scanning.
• The control gap is repo-level trust without execution scoping, which means configuration files need the same governance as build code.

Key terms

• Hook-Based Persistence: Hook-based persistence is a technique where malicious code is embedded in configuration that automatically runs during routine developer actions. In software supply chains, this can include editor tasks, session hooks, or workflow triggers that execute before the user notices the compromise.
• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.
• AI Tooling Exposure: AI tooling exposure is the risk created when assistants, plugins, and related local files can access code, secrets, or command execution. It matters because an AI system is often trusted with more context than a human would be granted in the same workflow.
• Secret Propagation: Secret propagation is the spread of tokens, API keys, or certificates from one workflow into another through code, configuration, or automation. In AI-heavy development, generated code can copy or preserve credentials faster than human reviewers can notice, increasing exposure across environments.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, machine identity security, and secrets management through the industry's only accredited NHI security programme. It helps practitioners connect identity controls to the broader security programmes that govern software delivery and AI-assisted development.