Rolling out Claude Code? Protect your team from Axios, LiteLLM, and Lightning.

You've secured your cloud. You've secured your CI/CD pipelines. You've secured identity. The developer workstation is the last unsecured surface in your infrastructure, and it's where your team's credentials, publishing tokens, and cloud keys all live.

In a six-week stretch this spring, three of the most widely used open source packages in the world were compromised and used to steal exactly those things off developer machines. Axios (npm, ~100M weekly downloads). LiteLLM (PyPI, ~96M monthly downloads). PyTorch Lightning (PyPI, the standard training framework for ML pipelines). The malicious versions were live for hours, not days. Existing tools didn't catch them at install time. The most recent attack was purpose-built to persist inside Claude Code and VS Code.

This post covers what these attacks have already cost real companies, and how to close the gap this quarter: visibility into developer workstations, protection at the install boundary, and governance policies that make short exposure windows work for you instead of against you.

What the exploits have in common

Three incidents in six weeks. Different ecosystems, different actors, same playbook. The full technical breakdowns: Axios (March 31, npm). LiteLLM (March 24, PyPI). Lightning (April 30, PyPI).

All three attacks shared the same characteristics. They started by compromising a popular package and releasing a malicious version. As soon as that version was installed, it collected cloud credentials, SSH keys, and publishing tokens and exfiltrated them in seconds. And they opened a backdoor to accept remote commands, with the most recent attack writing persistence hooks directly into Claude Code and VS Code so the stealer would re-fire every time a developer opened either tool.

None of these attacks were caught by CI/CD scanning tools at install time because the IOC didn't exist yet. CrowdStrike added Axios detection two weeks after the malicious versions were pulled. SCA tools like Snyk and BlackDuck fire after code reaches the pipeline, not when the package hits the machine. EDR sees processes, not packages. These tools aren't broken. They were built for a different threat model. The developer workstation is the target now.

What a single compromised workstation costs

IBM's 2025 Cost of a Data Breach Report found supply chain compromise costs $4.91 million on average and takes 267 days to resolve. In the US, breach costs hit a record $10.22 million. 63% of organizations have no AI governance policies. 97% of AI-related breaches lacked proper access controls.

The LiteLLM compromise gutted Mercor, which was previously valued at $10 billion. One poisoned package landed on a developer workstation, and from there attackers harvested cloud credentials and Kubernetes secrets, accessed Mercor's entire infrastructure through their Tailscale VPN, and walked out with 4 terabytes: source code, candidate records with Social Security numbers, and thousands of hours of video interviews used for identity verification. That biometric data can't be rotated like a password, and they’re losing senior execs, F500 contracts, and Meta paused all work with them.

Preventing exploits

First, establish workstation visibility

The operational framework here is the same one you've used for every other surface you've secured: define the risk, build a standard process around it, then build an enforcement plan. Steps two and three require step one, and on developer workstations, most organizations have never done step one.

Your CMDB knows about the laptop. Your MDM manages the OS. Your EDR monitors processes. None of them can tell you which npm packages are installed, which MCP servers are configured, which AI tools your developers are actually using, or whether they're signed into Claude Code with a personal account or company SSO.

When security teams first scan their developer fleet, many won't find an active malicious package (though some will). What they find is the health-state picture they didn't have before. Developers running AI agents under personal accounts that IT never sanctioned. MCP servers configured against API keys that aren't in the corporate secrets manager. Shadow AI tools that nobody tracks and nobody governs.

None of that is an active incident yet. All of it is risk surface you can now measure and act on.

That's what makes visibility the first step: it turns the developer workstation from an environment you manage by assumption into one you manage by data. You see which teams need help and which are already locked down. You see where policy gates need to go and what they need to allow through. You can enforce selectively, team by team, based on what's actually deployed, instead of rolling out blanket controls that punish the careful teams for the mistakes of the messy ones.

If you're deploying AI coding agents this quarter, do the assessment first. Run a scan across your developer fleet before you enforce anything. Find out what's already installed, what's talking to what, and where the gaps are. Every organization that does this finds something they didn't expect.

Protect the install boundary

Of all the supply chain risk on developer workstations, the biggest threat right now is packages. That's what all three of the incidents above exploited. So that's where interception starts.

A 2026 dev environment has five package managers, three operating systems, a dozen IDE configurations, and AI agents that install dependencies autonomously. You need a single policy layer that covers all of those surfaces, enforces your organization's risk profile, and is invisible to every developer workflow it touches.

Pinning your direct dependencies covers the 80% case. The problem is transitive. You pin axios, but axios doesn't pin its dependencies, and one of those pulls in plain-crypto-js because the version range allows it. Best practice for open source projects is to not pin their own dependencies, which means your direct pin is only as strong as your transitive dependency tree is disciplined.

Lockfiles fix this if your project uses them and your CI respects them. But lockfiles don't help when a developer runs npx some-tool on their laptop, or when an AI agent installs something into a fresh environment, or when somebody's debugging a script in a venv they spun up an hour ago. They don't help when an MCP server installs its own dependencies on first run. And they don't help with pip install against a requirements.txt that has loose constraints, which is most of them.

Pinning is necessary. It's not sufficient. And AI-driven development is widening that gap every quarter, because AI agents install packages constantly and don't always use the carefully-pinned path.

Registry firewalls have the same structural limit. They sit between the package manager and the registry, and they check installs that route through them. A lot of the installs that matter happen outside that path. New venv. AI agent installing into a fresh workspace. npx on a one-off tool. Debug container from an hour ago. WSL. These don't route through the corporate artifact registry. These are the installs where malicious packages land.

So you need a policy gate at the command level itself: between pip install and PyPI, between npm install and npm, on every machine where installs happen. That policy gate wraps the package managers your developers already use, so pip install still works exactly the way they expect. No new commands. No new tools to remember. No changes to how AI agents call package managers.

A protection layer that requires a developer to install it won't get used. A protection layer that requires developers to change their commands won't get adopted. A protection layer that requires AI agents to know about it won't get coverage. The policy has to be invisible to be universal.

Set governance policies

Every single one of the three attacks covered in this post was caught and pulled within hours. Axios in three. LiteLLM in five. Lightning in 42 minutes. The community is fast. PyPI and npm are fast. Security researchers are fast.

A package release age policy that rejects any version published less than 72 hours ago would have prevented all three of these incidents at your organization. The malicious version would have been quarantined and removed by the community before any developer in your company could pull it.

This is the single most powerful control in your toolkit for this class of attack, and if you have a tool like Safety you get it for free. It doesn't require detection, threat intel feeds, or vendor IOC updates. It's deterministic. The package is too new, so the install is blocked. The developer's install resolves to the most recent version that's past the cooldown window, and they never see an interruption.

Pair that with attestation checking, which rejects new versions of known major packages that don't carry the SLSA or OIDC provenance their previous versions had, and you have a second deterministic gate. The malicious axios versions had no provenance. The legitimate ones did. That's a check you can make at install time without any threat intel at all.

These two governance controls, applied consistently, would have closed the door on all three campaigns covered in this post without any developer needing to change their workflow, any analyst needing to write a detection rule, or any vendor needing to ship an IOC.

Endpoint security for rapid AI coding deployment

Imagine it's the morning of March 31, 2026. A developer on your team starts their day, opens a project, and their AI agent runs npm install to set up dependencies for a new feature. One of those dependencies is axios.

The install command isn't asking for a specific version. It's pulling the latest one that satisfies a range. With a cooldown policy in place, the resolver still does its job, but the policy gate filters out any version published in the last 72 hours. The malicious version is three hours old. It gets skipped. The install resolves to the prior clean release. No error. No interruption. The developer moves on with their morning.

For the developer who explicitly requests a brand-new version, the cooldown returns a clear message: this version was published less than 72 hours ago. They pick the prior version or wait. By the time the cooldown window closes, npm has pulled the malicious release.

No RAT on the laptop. No credentials exfiltrated. No incident response. No 03:00 UTC bridge call. No "rotate every cloud key in the company by Monday." Zero blast radius from an attack that compromised a package with 100 million weekly downloads. One policy, applied at the install boundary, covering every developer and every AI agent on every machine in the fleet.

Where to start

Get visibility into your developer fleet first. You probably don't know what's running on your developers' machines. Find out. Don't enforce yet, just assess.

Put package interception in place on developer workstations. Lockfiles and pinning are necessary, but they don't cover the cases that AI agents, ad-hoc installs, and fresh environments create. You need a policy layer at the install boundary itself.

Set a cooldown policy for new package versions. 72 hours is a reasonable starting point. This single control would have prevented every incident in this post.

The supply chain attack tempo has stepped up. Three world-class packages compromised in six weeks, a $10 billion company gutted through one of them, and IBM reporting that supply chain compromise is now the second most common attack vector with the longest resolution time of any. The tools that organizations rely on today were built for a slower world. The new picture is faster, AI-amplified, and aimed squarely at developer credentials. Get visibility, intercept at the install boundary, and use cooldowns to make the short exposure windows work for you instead of against you.

Safety handles endpoint security for AI coding

Safety is endpoint security for developer workstations. It covers all three layers described in this post: visibility, install-time protection, and governance policy enforcement.

Safety deploys silently via your existing MDM (Jamf, Intune, ManageEngine). No developer interaction required. Within minutes you have a real-time inventory of every package, AI tool, MCP server, and IDE extension across your developer fleet. The firewall wraps pip, npm, poetry, and uv at the command level, so developers keep typing exactly what they've always typed and the policy runs underneath. Cooldowns, attestation checking, license restrictions, and package allow/block lists are configurable as centralized policies that apply fleet-wide without touching a single developer machine individually.

One of our design partners ran their first scan across a 20-person engineering team and found 11,000 packages they didn't know about. That's not unusual. The developer workstation has been a blind spot for security teams because the tooling to see it didn't exist.

Want to find out what's on your developers' machines? Run an assessment. We can have results on your fleet by tomorrow morning.