Slopsquatting & coding agents: securing the AI software supply chain

In a short time, AI tools have gone from experiment to standard equipment in software development. In the Stack Overflow Developer Survey 2025, 84% of respondents said they use or plan to use AI tools in their development process (2024: 76%). They were actually in use among 78.5%, and daily among 47.1%. In 2025, only just under a third used AI agents at work (about 31%); 37.9% had no plans to do so.

A year later, the focus has shifted. In the 2026 survey (30,903 valid responses from 169 countries), coding assistants and agents are the most important AI use case at 66%, ahead of general-purpose chatbots (63%). Stack Overflow sums it up: the “overwhelming majority” now use coding assistants and agents daily (73%) – the figure covers both together, not agents alone. GitHub’s Octoverse 2025 points in the same direction: more than 180 million developers, around 36 million of them new, and almost 80% of newcomers already use Copilot in their first week. GitHub does not give an acceptance rate for the coding agent’s pull requests.

Assistants suggest, agents execute

For security, what matters is less how much code a model writes than what it is allowed to do itself. An assistant makes a suggestion that a human reads, accepts or discards. An agent works in the terminal, runs npm install or pip install, integrates MCP servers (Model Context Protocol, the interface to external tools and data sources) and skills (reusable instruction packages for agents), and reads repository content, issues and documentation as context. HiddenLayer points out that agents may adopt typosquatted packages with less human review and that remote MCP servers can change without the organization noticing (HiddenLayer, 16 July 2026).

That agents execute installation instructions without verifying ownership has been observed: researchers found 8,265 llms.txt or llms-full.txt files on 6,214 domains; 120 of them referenced unregistered packages or domains. After the researchers claimed some of these names with beacon packages, a Fortune 500 company checked in within an hour; the process chains pointed to Claude, OpenAI Codex and Nous Research Hermes (according to Schneier, citing Ars Technica, September 2026). This is not a hallucination – the names came from vendor documentation – but it follows the same logic: whoever claims a free name first determines what the agent installs. Versions are unreliable too: in around 37,000 analyzed AI upgrade recommendations, GPT-5 hallucinated 27.8% of component versions, according to Sonatype.

Three source articles and how to read them

The guiding idea of this deep dive: today, the software supply chain begins in the prompt. A package name that a model suggests or an agent picks up from a skill file is the first link in a chain that runs through registration, resolution and execution all the way to stolen tokens and spread. Anyone who evaluates only the model overlooks the stages at which an attack can actually be stopped.

In typosquatting, an attacker registers a name that is confusingly similar to a popular package and bets on typos, careless copying or automated tools. Public registries assign names on a first-come, first-served basis; a new account is all it takes. The patterns are limited in number:

From lone actors to assembly-line work

Neither Check Point nor Microsoft links these campaigns to AI; they are about typosquatting and brand impersonation. What stands out is the target profile: the attackers are after build environments, cloud roles and publishing tokens – exactly the permissions coding agents work with. Sonatype names the abuse of trust in well-known names, tools and release workflows as the most successful attack vector in the first quarter of 2026.

SANDWORM_MODE: typosquatting targets the agent

The transition is marked by a campaign described by Socket on 20 February 2026: at least 19 typosquatted npm packages, three of them Claude Code imitations, stole npm, GitHub, CI and crypto credentials as well as LLM API keys from nine providers. They also registered their own MCP server in the configuration of Claude Code, Claude Desktop, Cursor, VS Code Continue and Windsurf. Its tools, with innocuous names such as index_project or lint_check, contained a prompt injection: the assistant was to read SSH keys, AWS credentials, .npmrc and .env and conceal this step from the user. To spread further, the malware used stolen npm tokens, injected pull_request_target workflows and SSH as a fallback.

VamiSec assessment: here, the package is merely the door opener. The actual payload is a persistent change to the agent’s environment that takes effect in every future session with the developer’s permissions.

What the registries do – and where it ends

• Typosquatting check: PyPI says it automatically detects and flags potential typosquatting when a project is created; PyPI does not give thresholds or figures (2025 year in review).
• Quarantine: administrators can remove projects from the index without deleting them. Since August 2024, this has affected around 140 projects, only one of which was released again (PyPI, 30 December 2024). In March 2026, quarantine via trusted reporters was already being triggered automatically.
• Status marker: via PEP 792, the index APIs signal the status “quarantined”; installers are expected to warn about it.
• Response time: in 2025, PyPI handled more than 2,000 malware reports, 66% within four hours and 92% within 24 hours.

The limits are structural. All of these measures kick in after the upload; the window until removal remains. npm, too, responded to Shai-Hulud by blocking uploads that contained known indicators – likewise reactive. And a similarity check only detects what resembles an existing name. That is exactly where it fails with names a language model makes up from scratch.

The term slopsquatting is attributed to Seth Larson (Python Software Foundation); Andrew Nesbitt popularized it on 8 April 2025. It describes the following: a language model hallucinates a nonexistent package name, and an attacker registers it with malicious code. The authoritative measurement comes from Spracklen et al. (USENIX Security 2025, Distinguished Paper Award), who do not use the term themselves.

The researchers had 16 code models generate 576,000 code samples in Python and JavaScript. A package counted as hallucinated if it did not exist on PyPI or npm on 10 January 2024 – a lower bound. The 19.7% refers to package references, not to code samples.

Evidence from research and practice, 2023 to 2026

In 2023, Bar Lanyado showed at Vulcan Cyber that ChatGPT 3.5 recommended unpublished packages for more than 40 of 201 Node.js questions and more than 80 of 227 Python questions. For his follow-up study published at Lasso Security in 2024, he uploaded an empty package under the repeatedly hallucinated name huggingface-cli (real: huggingface_hub[cli]) – according to Lasso, it received more than 30,000 authentic downloads in three months. Alibaba listed pip install huggingface-cli in the first README commit of its GraphTranslator repository (26 February 2024).

No documented attack so far

As of 8 October 2026, there is no publicly documented case in which an attacker maliciously registered a demonstrably hallucinated name and victims installed it because of an AI suggestion. The claim that PhantomRaven (2025), for example, exploits slopsquatting is an assessment by Koi without published evidence. For the 53 Churilov names, too, Socket and InfoWorld see no malicious registrations.

VamiSec assessment: this is no all-clear. The preconditions are documented: hallucinations repeat, a small overlap spans models, and harmless placeholders received real installations, most recently apparently by agents. At the same time, a hit remains hard to detect: the name usually does not look like a typo, and Seth Larson considers it difficult, probably impossible, to quantify attempted installations of hallucinated packages (The Register, 12 April 2025). The absence of documented cases therefore does not prove that the risk is low.

Between the name suggestion and the damage lies execution. Package managers offer several trigger points for this, and not all of them can be switched off with a single setting. The common advice to disable lifecycle scripts (ignore-scripts) is correct but incomplete.

Six incidents, one pattern

1. 1
   AI CLIs as the attacker’s tools1ngularity/Nx – 26 August 2025

   Via a pull_request_target workflow with shell injection, attackers obtained the npm token and published malicious Nx versions for around four hours. According to Wiz, the payload searched for locally installed AI CLIs and launched them with --dangerously-skip-permissions, --yolo or --trust-all-tools to inventory secrets. According to GitGuardian, this succeeded on only 95 of 366 target systems (around 26%); in total, 2,349 unique secrets were made public.

2. 2
   Phishing, crypto clipperchalk/debug – 8 September 2025

   A maintainer fell for a phishing email from support@npmjs[.]help; the domain had been registered on 5 September 2025. Malicious versions of 18 popular packages (Aikido; Socket counts 19 versions) with more than 2 billion weekly downloads according to Aikido swapped wallet addresses in the browser by intercepting fetch, XMLHttpRequest and window.ethereum.

3. 3
   Worm via stolen tokensShai-Hulud – September 2025

   A self-replicating worm injected post-install scripts, searched for secrets using TruffleHog, environment variables and cloud metadata, and published further packages with captured npm tokens. GitHub removed more than 500 compromised packages; Wiz traces the campaign back to credentials from s1ngularity.

4. 4
   preinstall and runner backdoorShai-Hulud 2.0 – from 24 November 2025

   The second wave triggered as early as the preinstall phase, disguised as a Bun installer, registered infected hosts as self-hosted GitHub runners and, according to Wiz, created more than 25,000 malicious repositories. If it could neither steal credentials nor exfiltrate data, it attempted to destroy the home directory, according to Unit 42.

5. 5
   Compromised maintainer machineaxios – 31 March 2026

   After social engineering and the infection of his machine with a RAT (remote access trojan), axios 1.14.1 and 0.30.4 were published via the lead maintainer’s personal account with an additional dependency that downloaded further malware, including a RAT, in multiple stages – for around three hours. In its alert of 20 April 2026, CISA explicitly recommended ignore-scripts=true and min-release-age=7 (days) in .npmrc, as well as phishing-resistant MFA.

6. 6
   Valid provenance, agent as persistence locationTanStack / Mini Shai-Hulud – 11 May 2026

   Via a pull_request_target workflow and a poisoned Actions cache, attackers read the OIDC token for trusted publishing from runner memory and published 84 malicious versions of 42 @tanstack packages – with valid SLSA Build Level 3 provenance (StepSecurity). For persistence, the malware wrote a SessionStart hook into .claude/settings.json that runs node .vscode/setup.mjs every time Claude Code starts, plus a VS Code task with runOn: folderOpen.

Two lessons

First: provenance – the signed attestation of which repository and build a package comes from – proves origin, not harmlessness. To paraphrase StepSecurity, SLSA provenance confirms which pipeline produced an artifact – not whether it behaved as intended. In the Red Hat “Miasma” case, 32 tampered packages likewise carried valid signatures because the attackers used the legitimate OIDC publishing path (Microsoft, 2 June 2026). The npm documentation itself states that provenance does not guarantee content free of malicious code.

Second: tokens are the currency of spread. Most of these payloads looked for npm, GitHub, cloud or LLM API credentials and used publishing rights for the next wave. VamiSec assessment: every agent session in which plaintext tokens, cloud profiles or write access to a registry are within reach is a potential starting point for such a wave. Mini Shai-Hulud also shows that the agent’s own configuration becomes a persistence location.

In its framework of 28 July 2026, HiddenLayer puts one thesis at the center: the essential attack surface of a coding agent is not the model but its harness – prompts, tools, skills, MCP servers and the orchestration logic around the model. HiddenLayer sees the root of the attacks in misplaced trust. As early as 16 July 2026, the company had classified every source an agent reads as a potential entry point for indirect prompt injection.

Attack classes with evidence

OWASP classifies package hallucinations themselves under LLM09 Misinformation (“Unsafe Code Generation”), not under LLM03 Supply Chain. In the agentic list, ASI05 covers the case in which packages installed without review execute malicious code at installation or import; ASI04 recommends, among other things, checking for typosquats.

IDEsaster (Ari Marzouk) describes a new chain for Copilot, Cursor, Windsurf, Claude Code and other AI IDEs: prompt injection → tools → basic IDE features, such as remote JSON schemas or overwritten workspace settings. On top of that come flaws in the approval and sandbox logic of the agent CLIs, such as a bypassable confirmation dialog in Claude Code (CVE-2025-54795, CVSS 4.0: 8.7) or a sandbox escape via a working directory specified by the model in Codex CLI (CVE-2025-59532, CVSS 4.0: 8.6).

Guiding principle: security outside the model

Most cases share a structure: the model did what its context suggested. Where vendors made fixes, they did so not in the model but in the harness – by requiring re-approval of changed MCP configurations, a trust dialog before any execution, canonical path checks or tighter allowlists. Accordingly, HiddenLayer titles its monitoring layer: security must exist outside the model. VamiSec assessment: treat rules files, MCP configurations, hooks and skills like executable code – with review, versioning and approval – and every source the agent reads as untrusted input.

What HiddenLayer recommends (practice)

HiddenLayer titles the first layer of its framework of 28 July 2026 “Understand Every Trust Relationship”. It covers four subjects:

• All agents, models, harnesses, tools, MCP servers and skills in use – explicitly including shadow AI.
• The permissions of each agent and the systems it can reach.
• The origin and integrity of tools, skills and external services.
• The runtime interactions between agents, tools, repositories and external systems.

Origin and integrity are not a formality: remote MCP servers can change without the organization noticing (HiddenLayer, 16 July 2026). An inventory that contains only names therefore goes stale silently. To counter shadow AI, BSI and ANSSI recommend controlled company accounts instead of private access and clear rules on which tools may be used with which data. In its legally non-binding package manager recommendation of 10 March 2026, ENISA also advises visibility across all packages that AI tools select.

Implementation: agent bill of materials and SBOM (VamiSec recommendation)

We recommend maintaining the inventory as an agent bill of materials (AI-BOM): a machine-readable register that records for each agent the tool and version, model and provider, operating mode, connected MCP servers and skills with version or hash, rules files and the identity used. Alongside it sits the SBOM (software bill of materials, a list of all software components) for each release. In an emergency, both answer the same question: where is the affected component?

When it comes to SBOM depth, precision pays off. In Annex I Part II(1), the CRA requires an SBOM in a commonly used, machine-readable format covering at the very least the top-level dependencies – applicable from 11 December 2027; it does not currently prescribe a specific format. BSI TR-03183-2 (version 2.1.0), by contrast, requires recursive resolution for TR-compliant SBOMs and names CycloneDX 1.6 or later or SPDX 3.0.1 or later. Malicious code can arrive via transitive dependencies: the malicious version axios 1.14.1 added the dependency plain-crypto-js, which downloaded further malicious stages (CISA, 20 April 2026). We therefore recommend the recursive SBOM as a working standard – as best practice, not as a CRA obligation. According to ENISA (SBOM Adoption State of Play, June 2026), 24% of respondents need a full-depth analysis, but only 14% receive one.

Link to the attack chain

Visibility is not a break point, but it is the prerequisite for all the others. It makes stage 03 (Adoption) harder because new packages, MCP servers and skills stand out. Without an inventory, allowlists, isolation and monitoring cannot be enforced across the board. After an incident, it limits stage 07 (Spread): affected repositories, hosts and tokens can be named immediately instead of having to be tracked down first.

Regulatory anchor: financial entities under the full DORA framework must, under Art. 10(2)(d) of Delegated Regulation (EU) 2024/1774 (RTS on ICT risk management), track which third-party and open-source libraries are used by ICT services supporting critical or important functions – including versions and updates. The BSI’s Grundschutz++ includes, as a SHOULD requirement, documenting components via an SBOM before release (DEV.4.3, with reference to TR-03183-2).

What HiddenLayer recommends (practice)

Under “Limit the Impact of Compromise”, HiddenLayer lists five measures: least privilege by default, human approval for consequential actions, access only to approved tools, MCP servers and skills, restricting unnecessary outbound network connections, and reviewing system prompts and default configurations before deployment. The OWASP Top 10 for Agentic Applications 2026 extend least privilege to “least agency”: no autonomy where it is not needed. The guidance from CISA, NSA and Five Eyes partner agencies of 1 May 2026 likewise advises against giving agents broad access to sensitive data and critical systems.

Documented vulnerabilities show that defaults are not automatically secure: before version 1.0.4, Claude Code contained an overly broad list of “safe” commands through which file contents could be exfiltrated without a prompt (CVE-2025-55284, CVSS 4.0: 7.1). In GitHub Copilot (VS Code/Visual Studio), the confirmation requirement could be switched off entirely via prompt injection (CVE-2025-53773, see chapter 5).

Implementation in six steps (VamiSec recommendation)

1. 1
   Execution environmentIsolate

   Agents with terminal access and builds run in containers, devcontainers or VMs – without mounted host credentials, SSH agent or cloud profiles. If malicious code runs, it finds as little as possible that is worth stealing.

2. 2
   IdentityAssign a dedicated identity

   The agent does not work with the developer’s personal tokens but with its own narrowly scoped identity: only the repositories and scopes the task requires, no publish rights.

3. 3
   TokensShort-lived credentials

   Publish your own packages via trusted publishing (OIDC) instead of with stored tokens – generally available on npm since 31 July 2025, from npm CLI 11.5.1. Where tokens remain, choose the shortest practicable lifetime.

4. 4
   Tools, MCP, skillsEnforce allowlists

   Only approved tools, MCP servers and skills can be loaded; packages come exclusively via the internal proxy (see dependency hygiene).

5. 5
   NetworkRestrict egress

   Outbound traffic only to approved destinations. Even harmless tools transport data: in 2025, HiddenLayer showed how an SSH key was exfiltrated via the image URL of a diagram.

6. 6
   ConfigurationEnforce settings centrally

   Auto-approve off; approval required for installations, network commands and write access to agent configuration. Block flags such as --dangerously-skip-permissions, --yolo or --trust-all-tools – according to Wiz, the s1ngularity malware invoked local AI CLIs with exactly these. Where the tool supports centrally managed policies, these should take precedence over settings from the repository.

Human approval only works if the person can see what they are approving. In the Invariant Labs tool poisoning demo, the confirmation dialog did not display the full inputs. The BSI explicitly recommends confirmation by the user before an LLM executes functions (Evasion Attacks on LLMs, 6 November 2025). We recommend dialogs that show the command, package name and destination in full – and a few approvals that are taken seriously rather than constant confirmations.

Link to the attack chain

This layer provides the most break points: isolation without host secrets stops stage 06 (Access), egress control stage 07 (Spread), and the allowlist in the proxy stage 04 (Resolution). Human approval makes stage 03 (Adoption) harder. Short-lived, narrowly scoped tokens limit how far stolen credentials can reach.

Evidence for auditors

• Central configuration baseline per agent (auto-approve, approval requirements, blocked flags) with change history.
• Image or devcontainer definition without mounted credentials, plus the egress rules.
• Token inventory with identity, scope and expiry date; trusted publishing for your own packages.
• Samples from approval logs.

Regulatory anchor: for essential and important entities, Art. 21(2)(e) NIS2 and Section 30(2) sentence 2 no. 5 BSIG (German BSI Act) require security measures in acquisition, development and maintenance. Implementing Regulation (EU) 2024/2690 requires, for the types of entities named there, such as cloud and managed service providers, security requirements for development environments (Annex, point 6.2). Financial entities under the full DORA framework must separate the approval of changes from their request and implementation (Art. 17(1) RTS 2024/1774 on Art. 9(4)(e) DORA) – an agent that approves its own changes is hardly compatible with this (VamiSec assessment).

What HiddenLayer recommends (practice)

• Test agents with adversarial inputs before deployment (red teaming).
• Review proposed actions before execution.
• Vet third-party tools and skills – including hidden metadata.
• Approve specific versions instead of trusting “latest” indefinitely.

The last point targets the rug pull: an MCP server changes its tool description after it has been approved (Invariant Labs, 1 April 2025). MCPoison showed the same pattern in configuration: after the initial approval, a single commit was enough to swap the command of an MCP entry without a new prompt (CVE-2025-54136, see chapter 5). According to The Register, the unofficial npm package postmark-mcp shipped 15 inconspicuous versions before version 1.0.16 sent every outgoing email as a blind copy to a third-party address.

Hidden metadata is the second focus. Instructions in tool descriptions are invisible to users, but the model reads them (Invariant Labs); rules files can carry instructions in invisible Unicode characters (Pillar Security, 18 March 2025). Of 3,984 agent skills reviewed by Snyk, 76 were demonstrably malicious (5 February 2026, details in chapter 5).

Implementation: approval per component (VamiSec recommendation)

There is no special path for AI code. BSI and ANSSI state that AI coding assistants do not replace experienced developers and that productivity gains must be offset by more quality assurance (4 October 2024). Instruction files such as AGENTS.md help, but they are not a control. The OpenSSF guide for code assistants (1 August 2025) recommends instructing them not to add dependencies that could be malicious or hallucinated. This can reduce the risk – but the model can ignore the rule, and harmless-sounding skill instructions can even amplify package hallucinations (Hsu et al., accepted for EMNLP 2026).

Red teaming before rollout

1. 1
   Define scenarios

   Tasks that provoke package suggestions; prepared READMEs, issues and tool descriptions with hidden instructions; attempts to change agent settings or read credential files.

2. 2
   Run in the target configuration

   With exactly the model, harness, MCP servers and skills that are to be rolled out – in an isolated environment.

3. 3
   Measure

   How often does the agent invent packages? Does it follow injected instructions? Do the approval, proxy and isolation from layer 2 take effect?

4. 4
   Repeat

   With every change of model, tool version or integration, and as a regression test after incidents.

Link to the attack chain: validation makes stages 01 (Invention) and 03 (Adoption) harder because made-up names stand out in testing and review. Version approval prevents a silently changed component from being pulled in at stage 04 (Resolution). Evidence for auditors: red team report per agent configuration, allowlist with versions and hashes, review records for new dependencies, test evidence for AI-generated code.

Regulatory anchor: for financial entities under the full DORA framework, Art. 16 RTS 2024/1774 requires source code reviews with static and dynamic testing (para. 3), security testing of software packages no later than the integration phase (para. 4) and – where feasible – analysis and testing of open-source code before production use (para. 8). From 11 December 2027, the CRA requires manufacturers to carry out effective and regular security tests and reviews (Annex I Part II(3)).

HiddenLayer justifies the fourth layer succinctly: language models are designed to follow instructions – not to enforce security policies (paraphrased). A control that exists only in the prompt falls with the first successful prompt injection. Monitoring therefore starts at the operating system, network, pipeline and harness. The OWASP Top 10 for Agentic Applications call strong observability “non-negotiable”.

What HiddenLayer wants to observe (practice)

• Movements of sensitive data
• Tool usage and file operations
• Privilege escalation attempts
• Shadow AI activity
• API usage and unusual compute consumption

Detection ideas from real incidents (VamiSec recommendation)

The campaigns of recent months provide concrete patterns. According to StepSecurity, the Mini Shai-Hulud wave around TanStack gained a foothold via a Claude Code SessionStart hook and a VS Code task (details in chapter 4). According to Socket, SANDWORM_MODE registered its own MCP server in the configuration of Claude Code, Cursor and other tools. According to Microsoft, Miasma kept a dormant exfiltration channel via api.anthropic.com ready; according to Snyk, the exfiltration domain of the litellm releases had been registered one day earlier. Several waves launched Bun as the runtime – a way around Node-centric monitoring.

Telemetry via agent hooks

Several coding agents offer hook interfaces that launch custom programs on tool calls. We recommend using them to log tool calls, shell commands and file access centrally and to check risky calls before execution. The same interface, however, is a persistence path, as the TanStack wave shows; in Claude Code, hooks from project files at times ran without consent (Check Point, fixed on 26 August 2025). Hooks therefore belong in the centrally managed configuration – any change to them is itself an alarm signal.

Link to the attack chain: monitoring does not reliably stop any stage, but it shortens the time during which stages 05 (Execution), 06 (Access) and 07 (Spread) go unnoticed. The incidents show how short the windows are: the malicious TanStack versions were marked as deprecated after around 1.7 hours, and the axios versions were removed after about three hours. Our conclusion: your own detection must respond in hours, not days.

Regulatory anchor: for the types of entities named there, Implementing Regulation (EU) 2024/2690 requires protection against malicious and unauthorized software, including detection measures (Annex, point 6.9); for other NIS2 entities, it serves as guidance. The Five Eyes guidance on agentic AI (1 May 2026) explicitly calls for continuous monitoring.

What HiddenLayer recommends (practice)

Under “Security Requires Ownership”, HiddenLayer lists four points: a responsible person (owner) for every agent in production use, the inclusion of coding agents in existing threat models and AI governance programs, incident response procedures specifically for agentic AI, and regular review of permissions and trusted integrations. The Five Eyes guidance of 1 May 2026 likewise recommends integrating agentic AI risks into existing frameworks and performing threat modeling.

For NIS2 entities, this is a management responsibility. Management bodies must approve the risk management measures, oversee their implementation and can be held liable (Art. 20(1) and (2) NIS2). In Germany, Section 38 BSIG obliges the management bodies of essential and important entities to implement, oversee and undergo regular training; liability is governed by company law. A policy for AI coding tools should therefore be approved by management.

Building blocks of a policy for AI coding tools (VamiSec recommendation)

• Permitted tools, models and operating modes; use only via company accounts.
• Data classes: which information may go into which tool.
• Autonomy levels: what an agent may do on its own, what requires approval, what is prohibited.
• Package rules: sourcing only via the internal proxy, cooldown, no install scripts without approval.
• Approval process for MCP servers, skills and rules files, tied to a version or hash.
• Four-eyes principle for merges – including pull requests from agents.
• Logging, exception procedure and recertification of permissions and integrations, for example every six months.
• Training: since the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026), Art. 4 AI Act requires providers and deployers to take measures to support AI literacy, but not to guarantee a specific level.

In the threat model, the agent appears as an actor in its own right with permissions; rules files, skills, MCP servers and package sources are trust boundaries. ENISA’s draft on AI-assisted software development (v0.4, September 2026) describes STRIDE threats for this, such as slipping in malicious packages, skills or instruction files.

Incident response playbook: malicious package installed or agent compromised

1. 1
   ContainIsolate

   Take affected hosts, containers and runners off the network, terminate running agent sessions, halt pipelines that use the package. Preserve evidence before rebuilding.

2. 2
   ContainRotate credentials

   All reachable secrets: registry tokens, Git platform tokens, cloud and Vault access, model API keys. After Shai-Hulud, CISA explicitly advised rotation. Without the token inventory from layers 1 and 2, this step remains incomplete.

3. 3
   Clean upCheck lockfiles and caches

   Which repositories, lockfiles, package caches and CI caches contain the affected versions? In the TanStack case, the attack ran through a poisoned GitHub Actions cache – caches are part of the cleanup.

4. 4
   Clean upLook for persistence in the agent configuration

   Hooks and MCP entries in user and project configurations, VS Code tasks with runOn: folderOpen, new self-hosted runners and workflows, .pth files. When in doubt, rebuild rather than clean.

5. 5
   ReportCheck reporting obligations

   Since 11 September 2026, CRA manufacturers have been reporting actively exploited vulnerabilities in their products via the Single Reporting Platform simultaneously to the coordinating CSIRT and ENISA: early warning within 24 hours, notification within 72 hours, final report no later than 14 days after a corrective measure becomes available. Relevant if malicious code may have made its way into a shipped product (VamiSec assessment; obtain a legal review in each individual case). NIS2 and DORA entities check their own reporting channels in parallel.

6. 6
   LearnFollow up

   Document the cause, the stage reached and the missing break points, recertify permissions and integrations, inform registry operators and maintainers.

Link to the attack chain: governance makes stage 07 (Spread) harder because it is clarified in advance who rotates which tokens, who blocks what and who reports to whom. At the same time, it keeps the other layers up to date – without recertification, permissions and integrations creep upward.

When sourcing packages, the cooldown – a minimum age for new versions before installation – and blocking install scripts carry most of the load. Pay attention to the units.

Two limitations come with this. First, a cooldown catches malicious versions, which according to pnpm are usually discovered and removed within an hour – but not a hallucinated name that an attacker claims early and then waits. Second, ignore-scripts is incomplete: Git dependencies can execute code via their own .npmrc (countered by --allow-git=none from npm 11.10.0), URL dependencies such as those in PhantomRaven require --allow-remote=none (from 11.15.0), and no script block covers import code.

Configuration for builds and agents (VamiSec recommendation)

# CI builds and agents: only via the internal proxy (placeholder)
registry=https://registry.intern.example/
# no lifecycle scripts
ignore-scripts=true
# only versions older than 7 days (from npm 11.10.0)
min-release-age=7

# pyproject.toml: only versions older than 7 days (from uv 0.9.17)
[tool.uv]
exclude-newer = "7 days"
# per-package exceptions: exclude-newer-package

# pip from 26.1: duration in days, plus mandatory hashes
pip install --require-hashes --uploaded-prior-to P7D -r requirements.txt

Exempt security updates: a cooldown must not delay fixes. Dependabot and Renovate bypass it for security updates by default, and the package managers support exclusion lists (min-release-age-exclude, minimumReleaseAgeExclude, minimumReleaseAgeExcludes, exclude-newer-package). PyPI advises coupling cooldowns with vulnerability scans.

Lockfiles, review, proxy, provenance

In CI and agent environments, install only reproducibly: npm ci, pnpm install --frozen-lockfile, pip with --require-hashes. In the LiteLLM case, according to PyPI, around 40 to 50% of installations during the attack window were unpinned. OWASP describes the case in which an agent regenerates a lockfile from unpinned specifications and pulls in a compromised minor version – every new dependency and lockfile change therefore needs a named approval in the dependency review. Technically, an internal registry proxy with an allowlist enforces this; BSI and ANSSI recommend allowlisting permitted packages. A mere existence check is not enough: the attacker may have registered the name beforehand (Spracklen et al.).

npm audit signatures verifies registry signatures and provenance attestations (from npm 9.5.0); since 14 November 2024, PyPI has supported attestations under PEP 740, which according to Trail of Bits pip and uv do not verify automatically. Both prove origin, not harmlessness: the malicious TanStack and Miasma packages also carried valid provenance or signatures (see chapter 4). As an additional check, this is useful; as the sole approval criterion, it is unsuitable.

Regulatory anchor: ENISA’s legally non-binding recommendation on package managers (10 March 2026) advises using official, verifiable registries, lockfiles and integrity checks in CI/CD. Grundschutz++ includes, as SHOULD requirements, prohibiting external artifacts from unknown sources, testing their integrity and checking them for security updates (DEV.4.2, DEV.4.4, DEV.4.5); the 2023 Compendium requires trusted sources and the review of unknown components (CON.8.A6, CON.8.A20). Art. 21(2)(d) NIS2 and Section 30(2) sentence 2 no. 4 BSIG require supply chain security; from 11 December 2027, CRA manufacturers are subject to the due diligence obligation for third-party components under Art. 13(5) CRA – explicitly including open source.

The CRA, NIS2 and DORA take a similar approach: responsibility lies with whoever integrates the component or operates the system (VamiSec assessment). For the Cyber Resilience Act (CRA), this is illustrated by example 34 of the Commission guidelines C(2026) 5252 of 27 July 2026: an individual developer who publishes a free open-source library in a public package repository, and the repository itself, have no CRA obligations. From 11 December 2027, the due diligence obligation under Art. 13(5) CRA lies with the integrating manufacturer, on a risk basis in accordance with recital 34. The guidelines are non-binding. Whether a human or an agent chose the package makes no difference (VamiSec assessment).

Cyber Resilience Act: reporting obligation since 2026, due diligence from 2027

• Obligation since 11 September 2026 (Art. 14(1)–(2) CRA): report actively exploited vulnerabilities to the CSIRT and ENISA via the Single Reporting Platform (SRP) — early warning within 24 h, notification within 72 h, final report no later than 14 days after a corrective measure becomes available; also applies to existing products.
• Obligation from 11 December 2027: due diligence for third-party components, including free and open-source software (Art. 13(5) CRA), reporting vulnerabilities in components to their manufacturer or maintainer (Art. 13(6)), no shipping with known exploitable vulnerabilities (Annex I Part I(2)(a)).
• SBOM: Annex I Part II(1) requires at least the top-level dependencies; recursive resolution is only required by BSI TR-03183-2 v2.1.0 — good practice, not a CRA obligation. The CRA does not prescribe a format such as CycloneDX or SPDX; the Commission does not list an implementing act on this (Art. 13(24), an optional provision) (as of 27 July 2026).
• Fines (Art. 64(2) CRA): for infringements of Annex I, Art. 13 or Art. 14, up to EUR 15 million or 2.5% of worldwide annual turnover, whichever is higher.

NIS2 and BSIG: supply chain and development as minimum measures

NIS2 requires supply chain security (Art. 21(2)(d)) as well as security in acquisition, development and maintenance (point (e)). Art. 21(3), under which entities must also take into account the secure development procedures of their direct suppliers when choosing supply chain measures, is not reproduced verbatim in the BSIG; it can be applied via interpretation in conformity with the directive. In Germany, Section 30(2) sentence 2 nos. 4 and 5 of the BSIG (German BSI Act) has applied since 6 December 2025; the management body implements, oversees and is liable for culpable breaches of duty under company law (Section 38 BSIG, Art. 20 NIS2). For missing or undocumented measures, Section 65 BSIG provides for fines of up to EUR 10 million (essential entities) or EUR 7 million (important entities), and for entities with total turnover above EUR 500 million, up to 2% or 1.4% of total turnover. Implementing Regulation (EU) 2024/2690 is binding only for the types of entities listed in Art. 1, such as cloud, data center and managed service providers; for all others, it serves as guidance.

DORA: the precise anchors are in the RTS

Since 17 January 2025, DORA has required that changes to ICT systems be recorded, tested, assessed, approved, implemented and verified (Art. 9(4)(e) DORA), and it leaves financial entities fully responsible for ICT services (Art. 28(1) DORA). For freely sourced libraries, RTS 2024/1774 is more precise (full framework, Title II): track libraries used for critical or important functions (Art. 10(2)(d)), code reviews with static and dynamic testing (Art. 16(3)), test software packages no later than integration (Art. 16(4)), protect source code integrity (Art. 16(7)), review open-source code before production use where feasible (Art. 16(8)), separate the approval and implementation of changes (Art. 17(1)). An agent that merges its own pull requests does not fit with this (VamiSec assessment).

AI Act and product liability

Under the AI Act, a coding assistant is typically not a high-risk system, because software development is not listed in Annex III. For deploying companies, Art. 4 remains: since the Digital Omnibus (Regulation (EU) 2026/1744, in force since 27 July 2026), they must take measures to support AI literacy without guaranteeing a specific level. GPAI obligations apply to the model providers, not to the users. Under the Product Liability Directive (EU) 2024/2853, software is a product; for products placed on the market after 9 December 2026, the manufacturer is liable to natural persons also for defective components integrated under its control, and missing security updates do not exonerate it. The directive takes effect via national law; as of 8 October 2026, the German government draft (Bundestag printed paper 21/4297) has not been verified as promulgated.

Guidance: non-binding orientation

• ENISA, Secure Use of Package Managers (10 March 2026): explicitly names slopsquatting and recommends making AI-selected packages visible and checking them automatically in CI/CD.
• ENISA, AI-assisted software development (draft v0.4, September 2026): hallucinated packages, planted skills and instruction files — not yet final.
• BSI and ANSSI, AI Coding Assistants (4 October 2024): package hallucinations as a path to “package confusion”; plausibility checks, allowlisting, sandboxing.
• BSI Grundschutz++ DEV.4.2 to DEV.4.5 (SHOULD requirements): prohibit artifacts from unreliable or unknown sources, including packages and models; SBOM, integrity tests. 2023 Compendium: CON.8.A6, CON.8.A20.

The plan is a VamiSec recommendation and follows the attack chain: first you create visibility and close obvious gaps, then you put break points in place at stages 04 Resolution and 05 Execution, and finally you make the rules binding and measurable. The starting point is an honest stocktake, for example with the self-assessment on this page. Regulated companies start with what already applies: CRA reporting obligations since 11 September 2026, BSIG measures since 6 December 2025, DORA since 17 January 2025.

Ten metrics with target values

Measure what actually breaks the chain, not the number of training sessions. The target values are VamiSec recommendations, not regulatory thresholds; most can be collected automatically from proxy logs, CI configuration and central agent configuration. s1ngularity shows how risky modes without confirmation are: according to Wiz, the malware invoked locally installed AI CLIs with flags such as --dangerously-skip-permissions and --yolo to inventory secrets. Report quarterly to the management body; in NIS2 entities, it must oversee the implementation of the measures under Section 38 BSIG anyway.

Evidence for auditors

• Inventory of AI coding tools, agents, MCP servers and skills with owner, version and permissions (AI-BOM)
• Policy for AI coding tools, approved by the management body (Art. 20(1) NIS2; implementation and oversight under Section 38 BSIG)
• Versioned configuration of proxy, package managers, update bots and egress rules — Section 30(1) BSIG requires documenting compliance with the measures
• Approval records for new dependencies and agent extensions from the pull request history, with human approval of agent changes (for DORA financial entities: segregation of duties under Art. 17(1) RTS 2024/1774)
• SBOM per release: at least top-level dependencies (Annex I Part II(1) CRA, from 11 December 2027), preferably recursive in accordance with BSI TR-03183-2 v2.1.0
• Test evidence for software packages no later than the integration phase (Art. 16(4) RTS 2024/1774) and red teaming report on the agents
• Incident playbook with token rotation list and reporting channels under Art. 14 CRA (24 h / 72 h / 14 days), including exercise record
• Quarterly KPI report to the management body