TL;DR: Mini Shai-Hulud is the first in-the-wild supply chain attack to persist through AI coding agent sessions, using poisoned npm packages to plant hooks in .claude and VS Code configs that re-run every time a developer opens an infected project, according to Sonar. That shifts agent configuration files into the same control class as CI/CD workflows, where secrets hygiene, dependency verification, and rescans now matter for blast-radius reduction.
At a glance
What this is: Mini Shai-Hulud turns AI coding agent configuration files into a persistence layer by planting hooks that re-execute on project open.
Why it matters: It matters because IAM, secrets, and DevSecOps teams now have to govern agent session files as execution paths, not just local settings.
Context
Mini Shai-Hulud shows how AI coding agents expand the trusted computing boundary inside developer workstations. When agent configuration directories can trigger code on session start or folder open, ordinary project files become an execution path that sits between dependency hygiene, secrets exposure, and local persistence.
The governance gap is not just supply chain compromise. It is the assumption that editor and agent settings are inert, when in practice they can execute code with the same permissions as the developer session. That creates a direct intersection between software supply chain security, secrets management, and the identity of the agent session itself.
Key questions
A: Package-centric controls lose their main assumption: that execution starts when a dependency is installed. If repository-open files can launch scripts, then editor settings, assistant configuration, and workspace metadata become executable trust surfaces. Teams need to govern those files like code, because they can trigger secret theft before SCA or install-script policies ever fire.
Q: Why do poisoned dependencies create longer-lived compromise than a single install event?
A: Because the payload can write local persistence and then re-trigger whenever the developer opens an infected project. That means the compromise survives the original package installation and keeps creating chances to steal credentials, scan other repositories, and reinfect adjacent workflows.
Q: What signs show that a developer workstation has been used for AI agent persistence?
A: Unexpected session-start hooks, folder-open tasks, bootstrap scripts in agent directories, unusual downloads at project open, and credential theft from environment variables or local secret stores are all strong indicators. Security teams should also look for repeated re-execution across multiple repositories on the same machine.
Q: How should teams govern AI coding agents alongside secrets and supply chain controls?
A: Treat agent settings, dependency trust, and secret exposure as one control surface. If a package can alter local execution and the same session can read cloud or publishing credentials, then the risk is multiplicative. Governance should therefore combine provenance checks, secrets reduction, and persistence monitoring.
Technical breakdown
How session-start hooks turn agent settings into execution paths
AI coding tools often support hooks that run at defined lifecycle points such as session start or folder open. In this attack pattern, a malicious project drops configuration that points the agent or editor to a bootstrap script, which then executes without an obvious prompt. The important detail is that the hook lives in a trusted configuration file, so the malicious code inherits the user session's permissions rather than requiring a new exploit chain.
Practical implication: Treat agent configuration files as executable control points and subject them to the same review as build or CI workflows.
Why poisoned dependencies can create persistent agent compromise
Supply chain malware no longer needs to stop at one-off credential theft. A malicious package can write persistence into local configuration, then use the next agent session to re-run collection logic and scan the filesystem for more projects. That turns a package install event into a repeating compromise cycle across repositories on the same machine, which is why dependency trust and local persistence are now linked problems.
Practical implication: Pair dependency verification with checks for local persistence artifacts so a compromised package cannot survive beyond the first install event.
How secrets harvesting widens the blast radius
Once the bootstrapper runs, the attacker can target environment variables, SSH material, cloud credentials, npm tokens, and other locally stored secrets. That matters because the compromise is not limited to source code or one repository. It can extend into cloud access, package publishing, and downstream CI/CD systems if those credentials are present on the workstation or in the project tree.
Practical implication: Reduce the amount of reusable secret material present on developer endpoints and in repositories that agent tooling can reach.
Threat narrative
Attacker objective: The attacker wants durable access to developer credentials and a reusable persistence channel inside AI-assisted development workflows.
- Entry begins with a poisoned npm package or compromised maintainer account that places malicious code into a project dependency.
- Credential access follows when the bootstrapper harvests environment variables, SSH material, cloud credentials, and package tokens from the developer machine.
- Persistence is established when the malware writes hooks into .claude and VS Code configuration files so the payload re-runs on every infected session.
- Impact is achieved through repeated secret theft and cross-repository spread that can extend into other developer and CI/CD environments.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
- 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 coding agent configuration is now part of the attack surface. The key governance shift is that .claude and editor task files are no longer harmless preferences; they can encode execution semantics. That collapses the old separation between tool settings and runtime behaviour, which means security teams need to classify these files alongside other controlled execution paths.
Persistent agent compromise creates a new form of supply chain blast radius. A single malicious dependency can now survive beyond install time and keep re-triggering every time a developer opens an infected project. That makes the persistence layer more important than the initial payload, because the same compromise can keep harvesting credentials across multiple repositories and sessions.
Secret hygiene remains the limiting factor in how far the worm can go. The attack only becomes broad when it can reach tokens, keys, and environment variables that should never be sitting in easy reach of local tooling. This is the practical boundary where machine identity, human identity, and developer tooling intersect: the compromise moves laterally through whatever credentials the session can see.
Configuration trust assumptions are the named failure mode here. The attack worked because agent and editor settings were treated as trusted control data rather than executable content. That is a specific governance gap, not a vague malware problem, and it should push teams to review which local files are allowed to initiate code in development environments.
Supply chain security for AI-assisted development now needs identity-aware controls. This is not only a package integrity issue; it is also about who or what is allowed to act inside a developer session after a dependency change. Practitioners should treat agent hooks, package trust, and credential exposure as one governance surface, not three separate problems.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Read next: AI Coding Agents Security Guide
What this signals
Agent persistence is the new control boundary: when a development tool can re-run code at session start, the real question is not whether the package is malicious, but whether local settings can be made safe enough to withstand repeated execution. Security teams should now review AI coding agent files the way they review build hooks and workflow files.
Persistent compromise and secret exposure reinforce each other: a worm that can survive in .claude or editor configuration becomes far more dangerous when the same workstation holds cloud keys, npm tokens, and SSH material. That makes secret reduction on developer endpoints a direct blast-radius control, not just hygiene.
For practitioners
- Audit agent and editor persistence files Inspect .claude/settings.json, setup scripts, and .vscode/tasks.json across repositories for hooks that trigger on session start or folder open.
- Verify dependency provenance before execution Block unreviewed packages and watch for malicious or recently altered dependencies that can write persistence into local project settings.
- Reduce secret exposure on developer endpoints Remove reusable cloud credentials, npm tokens, SSH material, and other secrets from machines and repositories that agent tools can read.
- Run periodic rescans on active branches Use recurring software composition analysis to catch dependencies that were clean at install time but later became malicious.
- Check for system-level follow-on persistence Look for additional services or launch items that indicate the compromise moved beyond project-level hooks into user-level persistence.
Key takeaways
- AI coding agent configuration files can now act as repeatable execution paths, which changes how teams should classify developer workstation risk.
- A poisoned dependency is more dangerous when it can leave behind persistence that survives beyond the original install and replays on later sessions.
- Reducing accessible secrets on developer machines is one of the few controls that directly limits how far this kind of supply chain compromise can spread.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The attack steals secrets from developer machines and repository-adjacent files. |
| NHI-05 — Overprivileged NHI | The agent session and local tooling operate with more privilege than the attack should be able to reuse. | |
| NHI-07 — Long-Lived Secrets | The worm is most damaging where reusable credentials remain available to local tooling. | |
| Recommendation — Scan agent, editor, and project paths for exposed NHI secrets and revoke anything found. Limit the privileges available to agent sessions and isolate them from high-value credentials. Replace long-lived credentials with short-lived alternatives wherever developer workflows can reach them. | ||
| MITRE ATT&CK | TA0006;TA0003;TA0008 — Credential Access; Persistence; Lateral Movement | The incident combines credential theft, persistence in agent configs, and spread across repositories. |
| Recommendation — Map the attack path to TA0006, TA0003, and TA0008 to prioritise detection on credential theft and replay. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Developer and agent access should be constrained so local execution cannot reach everything of value. |
| Recommendation — Review entitlements on developer endpoints and narrow access to the minimum needed for agent workflows. | ||
| CIS Controls v8 | CIS-5 — Account Management | The article shows how stolen tokens and accounts become the mechanism for spread and exfiltration. |
| Recommendation — Harden account lifecycle controls so stolen developer and automation credentials are revoked quickly. | ||
Key terms
- Agent Session Persistence: A persistence technique where malicious code is stored in AI coding agent or editor settings so it runs again whenever a project opens. It matters because the compromise is no longer tied to a single install event and can re-trigger across multiple development sessions.
- Execution Semantics: The behaviour a command or action produces when it is actually run, which can differ from the surface text a policy engine inspects. In agentic systems, security depends on checking execution semantics because parsing alone may not capture redirection, chaining, or shell behaviour.
- Supply Chain Worm: A supply chain worm is malware that uses one compromise to propagate into adjacent packages, repositories, or automation systems. In identity terms, it becomes far more dangerous when it can harvest and replay secrets that let it publish, move, or persist without further exploitation.
- Secrets blast radius: Secrets blast radius is the amount of access exposed when a single credential is compromised or over-shared. It depends on privilege scope, reuse, export rights, and downstream trust relationships, not just on whether the secret was stored securely.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, secrets management, and workload identity. It helps practitioners connect identity controls to the broader security programme they run.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org