The most actively used part of a company’s IT setup is the computer used by developers. This laptop is where login details are made, tried out, saved, copied, and then used again across different services, automated programs, tools for building software, and now artificial intelligence on the user’s device.

In March 2026, a group known as TeamPCP showed just how important developer computers are. Their attack on the software supply chain through LiteLLM, a widely used AI software collection that’s downloaded millions of times daily, turned developer computers into systems that automatically collected login details. The harmful software only needed to get to the unprotected login information that was already saved on the computer’s storage.

The attack was simple in how it was carried out but had a big impact. TeamPCP broke into versions 1.82.7 and 1.82.8 of LiteLLM on PyPI, adding harmful software that steals information and starts working when developers install or update the software collection. The malicious software then collected SSH keys, cloud login information for AWS, Azure, and GCP, Docker settings, and other sensitive information from the developer’s computers.

PyPI removed the malicious software collections within a few hours after they were discovered, but the time it was active was still significant. GitGuardian’s analysis revealed that 1,705 PyPI software collections were set up to automatically download the compromised LiteLLM versions as dependencies. Popular software collections such as dspy (5 million monthly downloads), opik (3 million), and crawl4ai (1.4 million) would have caused the harmful software to start when installed. This had a domino effect, meaning that companies that didn’t even use LiteLLM directly could still be affected through secondary dependencies.

This type of attack isn’t new, but it’s now more obvious. The Shai-Hulud campaigns showed similar methods being used on a large scale. When GitGuardian checked 6,943 compromised developer computers from that event, researchers found 33,185 unique login details, with at least 3,760 still working. More surprisingly, each working login detail appeared in about eight different places on the same computer, and 59% of the affected systems were CI/CD runners rather than personal laptops.

Attackers are now getting into the toolchain through compromised dependencies, harmful plugins, or tainted updates. Once they’re in, they collect local data with the same systematic way that security teams use to find weaknesses, but they’re looking for login details saved in .env files, shell settings, terminal history, IDE settings, tokens that have been saved, build files, and AI memory storage.

The LiteLLM malware worked because developer computers have a lot of login details in unprotected form. These secrets end up in source code, local settings files, debugging information, copied terminal commands, environment variables, and temporary scripts. They collect in .env files that were supposed to be for local use only but became a permanent part of the codebase. Convenience turns into leftover data, which becomes an opportunity for attackers.

Developers are running agents, local MCP servers, CLI tools, IDE extensions, build pipelines, and retrieval workflows, all of which need login details. These credentials spread across predictable locations that malware knows to look in: ~/.aws/credentials, ~/.config/gh/config.yml, project .env files, shell history, and agent settings directories.

It’s important to build continuous protection across every developer device where login details gather. GitGuardian addresses this by expanding secrets security beyond code storage to the developer’s computer itself.

The LiteLLM attack showed what happens when login information collects in unprotected form across developer devices. Here’s what you can do to reduce that exposure.

Start with awareness. Think of the workstation as the main place for scanning for secrets, not something to consider later. Use ggshield to scan local storage for login details that ended up in code or are left in Git history. Scan file system paths where secrets collect outside Git: project workspaces, dotfiles, build files, and agent folders where local AI tools make logs, caches, and “memory” stores.

Don’t assume that environment variables are safe just because they’re not in files. Shell settings, IDE settings, and generated files often keep environment values on disk for a long time. Scan these locations the same way you scan repositories.

Add ggshield pre-commit hooks to stop creating new leaks in commits while cleaning up old ones. This turns secret detection into a built-in safeguard that catches mistakes before they become incidents.

Finding something without fixing it is just creating noise. When a login detail leaks, fixing it usually needs coordination between several teams: security finds the exposure, the infrastructure team owns the service, the original developer might have left the company, and product teams worry about production problems. Without clear ownership and workflow automation, fixing it becomes a manual process that’s given lower priority.

The solution is to treat secrets as managed identities with clear ownership, lifecycle rules, and automated ways to fix them. Move login details into a central secure system where security teams can enforce rotation schedules, access rules, and usage monitoring. Connect incident management with your existing ticketing systems so fixing happens in context rather than needing constant tool-switching.

Agentic tools can read files, run commands, and move data. With OpenClaw-style agents, “memory” is literally files on disk (SOUL.md, MEMORY.md) stored in predictable locations. Never paste login details into agent chats, never teach agents secrets “for later,” and routinely scan agent memory files as protected data stores.

The fastest way to reduce the spread of secrets is by removing the need for whole types of shared secrets. On the human side, use WebAuthn (passkeys) to replace passwords. On the workload side, switch to OIDC federation so pipelines stop relying on stored cloud keys and service account secrets.

Start with the highest-risk locations where leaked login details cause the most damage, then expand. Move developer access to passkeys and switch CI/CD workflows to OIDC-based authentication.

If you can’t get rid of secrets yet, make them short-lived and automatically replaced. Use SPIFFE to issue cryptographic identity documents (SVIDs) that rotate automatically instead of relying on static API keys.

Start with long-lived cloud keys, deployment tokens, and service credentials that developers keep locally for convenience. Shift to short-lived tokens, automatic rotation, and workload identity patterns. Each move is one less durable secret that can be stolen and used as a weapon.

The goal is to reduce the value an attacker can get from any successful entry point on a developer’s device.

Honeytokens offer temporary protection. Place decoy login details in locations that attackers systematically target: developer home directories, common settings paths, and agent memory stores. When these tokens are harvested and validated, they create immediate alerts, shortening the time to detection from “finding damage weeks later” to “catching attacks as they happen.” This isn’t a final solution, but it changes the response time while systematic cleanup continues.

Developer devices are now part of your critical infrastructure. They sit at the intersection of privilege, trust, and execution. The LiteLLM incident proved that attackers understand this better than most security programs. Companies that treat developer devices with the same management rules already applied to production systems will be the ones that survive the next supply chain compromise.