At Unosecur, we have spent the last several years conducting identity risk assessments across organizations of different sizes, industries and security maturity levels. One pattern has become impossible to ignore: Teams that have invested significantly in perimeter defenses, endpoint protection and vulnerability management are still getting caught off guard—not because their tools failed, but because the attack landed in an area nobody was watching. Currently, that place is AI credential infrastructure.

Two recent incidents made that visible in a way that no framework document could. On March 24, 2026, an attacker did not exploit a code vulnerability in LiteLLM. They compromised the publishing credentials of a PyPI package maintainer. Two malicious versions went live. The package had 3.4 million downloads that day. Every environment running those versions had OpenAI keys, Anthropic credentials, AWS secrets and Kubernetes tokens exfiltrated to attacker-controlled servers. Nothing crashed. Nothing flagged. It just collected everything and sent it out.

One week later, Anthropic’s Claude Code npm package leaked 512,000 lines of source code via a debug file. Researchers found that malicious repositories could steal Anthropic API keys by cloning them. Developers’ machines were compromised before they ran a single line of code.

Neither attack exploited a product weakness. Both exploited credentials. Firewalls did not stop them and scanners did not catch them because the actual attack surface was never where most teams were pointed.

A Structural Problem, Not A Process One

For two decades, API authentication was manageable: one key tied to one service, with a predictable blast radius if things went wrong. That model does not hold in AI infrastructure.

Today, a single AI provider credential can unlock unrestricted access across models, operations and environments without scope limits. The risk has scaled fast. GitGuardian’s State of Secrets Sprawl 2026 reports 1,275,105 AI service credentials leaked in 2025, up 81% year over year, with LLM infrastructure secrets leaking five times faster. Of credentials valid in 2022, 64% remained active in January 2026, leaving years of exposure.

Why The Standard Playbook Falls Short

The security industry’s response to credential exposure has followed a familiar pattern for years: rotation policies, vault management and more aggressive scanning. These are not bad practices, but they were built for a world where secrets were fewer, environments were more contained and exposure windows were shorter.

AI infrastructure operates differently. A credential does not live in one place. It propagates into Docker images, Terraform state, CI/CD logs and environment snapshots across teams and pipelines. By the time rotation kicks in, the key may already be in use elsewhere. By the time a scanner flags an exposure, the window has been open for days.

The Weaviate incident in 2025 illustrated this clearly. A researcher discovered an exposed OpenAI API key in a public repository. When tested, the key returned a quota exhaustion error, indicating that attackers had found it first and were actively using it before anyone in the organization had noticed. Revocation came after the fact.

The tools worked as designed. The architecture made them insufficient.

Identity Has Changed Its Role

For most of security history, identity flowed in one direction. Users are authenticated to applications, and applications are authenticated to infrastructure. The model was predictable and centralized.

Researchers who identified the Claude Code vulnerabilities noted this directly: a stolen Anthropic API key was not worth just billing fraud. It was worth assessing the entire organizational deployment and every conversation running through it. One credential became leverage over an entire AI infrastructure. That’s a different category of risk from a traditional breach. It is the ability to manipulate how your systems reason and respond.

Applying Least Privilege Where It Has Been Missing

Least privilege is not a new concept. What is new is that it has not been applied to AI. An OpenAI API key today functions as a master key with no operational constraints.

The alternative is to scope credentials to the work they actually need to do. A fraud detection service should have access to fraud models and nothing beyond that. A customer-facing assistant should access only inference endpoints. An analytics pipeline should read logs and stop there. Staging environments should operate on separate credentials from production. The principle is straightforward: When a credential is compromised, the attacker should inherit only the permissions that the workload actually requires, not the entire infrastructure.

This is not a new security capability. It is a governance decision that most organizations have yet to make for their AI systems.

LiteLLM and Claude Code were not outliers. They were early signals of a shift already underway. Supply chain attacks are growing more sophisticated, vulnerability disclosures are accelerating, and as organizations integrate AI deeper into critical operations, the value of a single compromised credential will only increase.

The organizations that manage this well will be those that apply the same discipline to AI identity that they have spent years building around human and non-human identities elsewhere: clear ownership, activity-based least privilege, continuous runtime visibility and the assumption that any credential in the wild is already compromised.

The attack surface has moved. The governance model needs to follow.

Stay aware. Stay secure.

Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?

Source link