AI developer tooling is starting to leak the thing companies thought was not part of the software supply chain: the conversation.
That is the lesson from malicious packages aimed at AI workflows. The old supply-chain story was stolen tokens, poisoned dependencies and abused CI runners. Those are still active. But the newer attacks show a wider target set. Prompts, completions, agent configuration and IDE automation files are now worth stealing because they carry source code, architecture notes, customer details, credentials and operating procedures.
This is not prompt injection as a trick. It is data theft through tools developers increasingly trust with production context.
The Proxy Was The Payload
JFrog’s April analysis of hermes-px is the cleanest example because the package marketed itself as a privacy tool. The malicious PyPI package presented an OpenAI-compatible “secure AI inference proxy” and promised anonymous routing through Tor. JFrog found the opposite: the package abused a Tunisian university’s private AI endpoint, bundled a stolen and rebranded Claude system prompt, laundered provider references from responses and exfiltrated user messages and AI responses to an attacker-controlled Supabase database (JFrog).
The important detail is not just that a PyPI package was malicious. That is no longer novel. The important detail is the object being stolen.
hermes-px did not need to wait for a developer to paste an API key into a terminal. It sat directly in the inference path. JFrog says the telemetry module sent the original request messages and full response content after every call, while bypassing the Tor-proxied session and using the victim’s real network connection. It also noted that telemetry was enabled by default and could be disabled only through an environment variable that did not clearly explain what was being collected (JFrog).
For enterprise teams, that changes the incident question. The first question is not only which credentials were exposed. It is which prompts and completions passed through the tool.
That inventory can be ugly. Developers put proprietary code into prompts. They paste stack traces with internal hostnames. They ask models to reason about unreleased products. They include snippets from customer logs. They describe deployment workflows. A proxy that captures both sides of the exchange is not stealing chat history. It is stealing an engineering notebook with a working memory.
The Worm Learned Where Developers Keep Secrets
The Shai-Hulud follow-up expands the same risk from prompt flow to developer environment flow.
JFrog’s May write-up on “Shai-Hulud: Here We Go Again” says the campaign affected more than 170 npm packages and 2 PyPI packages whose combined downloads exceeded 200 million per week. The npm packages used malicious preinstall loaders and large obfuscated JavaScript payloads. The PyPI packages used import-time downloaders, including a compromised mistralai package whose import path could fetch and start a remote Python payload (JFrog).
The updated PyPI payload matters because of its target list. JFrog says it collected local credential files, shell histories, SSH keys, .env files, Terraform state, Docker environment data, Tailscale state and WireGuard configuration. It also targeted cloud providers, Kubernetes, HashiCorp Vault, password managers and developer-tool configuration, including Cursor MCP, VS Code MCP, Claude Desktop, Continue, Codeium, OpenCode, Kilo and Zed settings (JFrog).
That list reads like a map of the modern AI developer workstation.
The workstation is no longer just where code is written. It is where local agents hold project instructions, model provider keys, tool permissions, MCP server settings, context caches and increasingly broad automation rights. When malware searches those files, it is not treating AI tooling as a novelty. It is treating it as a credential and context store.
This is the part many security programs still underprice. AI tools compress useful context into local configuration and session state. Useful context is exactly what attackers want.
Persistence Moved Into The Agent
The Mini Shai-Hulud reporting shows the next step: agent and IDE configuration as a persistence mechanism.
Lyrie’s write-up says four official SAP npm packages were published with malicious code on April 29, and that the campaign used Claude Code SessionStart hooks and VS Code folderOpen tasks for persistence (Lyrie). StepSecurity’s technical analysis is more explicit: the payload committed .claude/settings.json, .vscode/tasks.json, loader files and a copied payload into accessible repositories, using a routine-looking commit message and a claude@users.noreply.github.com committer identity (StepSecurity).
That matters because the infection can survive removal of the original poisoned package. StepSecurity says the VS Code task can run when a developer opens the project folder, while the Claude Code hook can run at the start of a session in that repository. A developer who clones an infected repo can re-trigger the stealer through normal tooling behavior (StepSecurity).
This is a supply-chain attack using the development environment as the runtime.
The configuration files are legitimate. The hooks are legitimate. The IDE behavior is legitimate. That is the problem. Attackers do not have to invent a new execution primitive when the toolchain already provides one for convenience. They only have to place a plausible file in a plausible location and let trusted automation do the rest.
Trust Is The Attack Surface
ReversingLabs’ 2026 software supply-chain report release frames the broader pattern correctly. Its report says detections of malicious open-source packages rose 73% in 2025 and argues that attackers are exploiting trust, scale and automation across development pipelines, including AI development workflows (ReversingLabs).
That is the connective tissue across these incidents.
hermes-px exploited trust in a drop-in AI client. Shai-Hulud exploited trust in package installation and import paths. Mini Shai-Hulud exploited trust in repository configuration, IDE tasks and agent lifecycle hooks. None of those require a user to make an exotic security mistake. They require normal developer behavior at speed.
AI makes that worse because the tooling is designed to absorb context. A package manager installs code. An IDE opens a folder. An agent reads configuration and history. An inference proxy sees the entire prompt-response exchange. Each layer is useful because it is close to the developer’s work. Each layer is dangerous for the same reason.
Security teams should stop treating prompt data as a soft privacy concern and start treating it as supply-chain material.
The controls are not mysterious. Ban unapproved inference proxies from production work. Require allowlisted model clients and pinned package sources. Monitor for new .claude, .vscode/tasks.json, MCP and agent-configuration changes in repositories. Treat agent hooks like executable startup scripts. Block install-time scripts in CI unless explicitly approved. Rotate secrets after prompt-exfiltration incidents, but also review the prompts and completions themselves for code, customer data and operational details.
For vendors, the bar is also moving. AI tools need clearer disclosure of telemetry, local storage, hook execution and network paths. A “privacy proxy” that quietly logs conversations is malware with a nicer README. An agent that runs project hooks needs enterprise policy controls, audit logs and sensible defaults. Developer delight is not a security model.
The deeper implication is structural. The AI development stack is becoming a high-context supply chain. The assets are not only packages, tokens and containers. They are prompts, completions, tool manifests, agent memories and configuration files that decide what gets executed next.
Attackers have noticed. Defenders should catch up before the next incident response starts with the question nobody logged: what exactly did the model see?
Discussion
Sign in to join the discussion.
No comments yet. Be the first to share your thoughts.