Developer secrets are under heavier attack than they were a year ago, and the old habit of leaving credentials in plain-text .env files is no longer defensible, according to the source article. It says supply-chain compromises, CI incidents and AI agent behavior have created more chances for tokens, SSH keys and cloud credentials to leak.
The article points to a series of incidents in 2026 that show how fast this problem has escalated. In March, two versions of the Axios HTTP client were injected with a malicious payload that activated through an npm post-install hook, according to security researcher John Hammond. He said the trojan performed system reconnaissance, including enumerating user directories, filesystem roots and running processes, and sent that data to a control server.
Also in March, the litellm Python package was compromised after a maintainer’s PyPI account was taken over, according to the project blog. litellm is an AI API router with more than three million daily downloads, and the payload reportedly scanned for environment variables, SSH keys and cloud provider credentials before transmitting them to an attacker-controlled server.
The same pattern appeared again in April. The @bitwarden/cli package on npm was compromised, and the malicious version targeted SSH keys, npm credentials, cloud tokens and Claude configuration files that could contain MCP server credentials, the article says. Bitwarden is a password manager used by over ten million people and 50,000 businesses. It took 90 minutes for the malicious release to be detected and removed from npm.
CI systems were also hit. In March, a compromised version of the Trivy security scanner was published, and Palo Alto Networks said the breach exposed CI/CD secrets, planted persistent backdoors on developer machines and spread a worm across dozens of npm packages. The malware harvested SSH keys, cloud credentials for AWS, GCP and Azure, Kubernetes tokens, Docker registry credentials, database passwords and TLS private keys, then exfiltrated them to a control server.
In April, malicious images were pushed to the checkmarx/kics Docker repository, according to the article. KICS is an open source security tool with more than 5 million total downloads. The malware captured scan output, which could include secrets, credentials, cloud resource names and internal topology, and sent it to an attacker-controlled endpoint.
The article argues that AI agents have made the exposure problem worse in a second way. In one case, PocketOS lost three months of customer data when an AI agent deleted its production database and backups using an unencrypted production API token stored on the user’s machine. The agent, Cursor running Claude Opus 4.6, did this while supposedly fixing a configuration issue, according to the article.
The point, the article says, is that agents should not be trusted with credentials they should never be able to use. Prompting and harness safeguards can reduce risk, but they are not hard guarantees. If an agent can reach a powerful secret, one failure is enough.
The article also highlights the growth of the Model Context Protocol, or MCP, which connects agents to external APIs and services. It says developers are now wiring broad production credentials into local harness configs, including files like ~/.claude.json, which are then attractive targets for credential harvesters. Prompt injection is another risk: this is when untrusted content, such as a web page or repository, poisons an agent’s instructions and turns it into a local secret exfiltration tool.
The recommended response is active secrets management, not passive storage. The article says the first rule is not to store credentials at all when possible. If credentials must exist, they should not be plain text, should be short-lived, and should be narrowly scoped.
On developer machines, the article recommends removing long-lived credentials from local storage, especially AWS keys in ~/.aws/credentials and npm tokens in ~/.npmrc. It suggests using AWS Identity Center and short-lived STS tokens instead of long-lived IAM user keys, and avoiding local npm login when possible in favor of CI-based publishing with OIDC.
For SSH, the article recommends moving keys off disk and onto hardware, such as a YubiKey or a hardware enclave. That keeps the private key on the device and makes use depend on physical presence, touch or a passcode. For secrets that must remain on disk, the article recommends encryption at rest using sops, with hardware-backed keys where possible.
It also suggests direnv as a way to decrypt secrets only when entering a project directory, load them into the environment, and remove them when leaving. The article notes that environment variables still have exposure risks, including visibility to processes running as the same user and inheritance by subprocesses.
For CI, the article says long-lived credentials should be removed in favor of OpenID Connect, or OIDC. OIDC lets a workflow exchange a short-lived identity token for narrowly scoped cloud or publishing credentials, which reduces the damage if a pipeline is compromised.
The article’s bottom line is simple: secrets should no longer sit unprotected in .env files, local configs or CI systems. The security baseline for development now has to assume that local machines, package installs and agent workflows will be targeted.
