A Teenage Hacking Crew Beat NVIDIA, Cisco, and AWS in 40 Minutes. Identity Is Why.

Team PCP calls its own operation ramshackle. It still walked away with live credentials from 2,500 companies, because almost nothing in a standard identity program is built to check whether a credential is still good.

The 40 minutes that mattered more than the terabytes

In March, an attacker group calling itself Team PCP got read access to the GitHub Actions pipeline for Trivy, the open-source vulnerability scanner that a huge share of the industry, including AI and cloud teams, runs against its own code. Trivy's own maintainers had already been compromised once that month. They rotated their automation token in response. They just didn't fully revoke the old one. For roughly three weeks, the half-retired token still worked, and Team PCP used it to keep force-pushing malicious code into projects that depended on Trivy, LiteLLM among them.

LiteLLM is a popular open-source gateway that lets an engineering team route calls to more than 100 different AI providers, OpenAI, Anthropic, Gemini, Bedrock, through a single interface. Because LiteLLM's own developers used Trivy in their build pipeline, the poisoned scanner had legitimate access to LiteLLM's PyPI publishing credentials. Team PCP took those credentials and published two malicious versions of LiteLLM itself, 1.82.7 and 1.82.8, on March 24. The payload fired the moment Python started, before anyone even imported the library, and quietly copied whatever credentials were sitting in memory: cloud keys, SSH keys, Kubernetes tokens, Salesforce and Slack secrets, the AI provider keys LiteLLM exists to hold on your behalf.

The malicious packages were live on PyPI for about 40 minutes before someone caught them.

This month, two research firms, CloudSEK and Hudson Rock, published what those 40 minutes actually cost. A compressed 153-gigabyte archive of exfiltrated data, which researchers say balloons to well over 100 terabytes once unpacked. Credentials tied to more than 2,500 organizations. Researchers estimated roughly 434,000 exposed CI/CD pipelines, though CloudSEK has since cautioned that figure reflects captured files and exfiltration events rather than confirmed, distinct pipelines. The high-confidence list of affected companies reads like a Fortune 100 roster: NVIDIA, AWS, Cisco, Samsung, Salesforce, ServiceNow, Siemens, Deloitte, Volkswagen, FedEx, and dozens more, according to both firms' published research.

Independent researcher Kevin Beaumont, who confirmed the leaked data was legitimate, described Team PCP as "a ramshackle but extremely capable gang largely made up of teenagers." That's the detail worth sitting with. This wasn't a nation-state with a zero-day budget. It was one popular dependency, one incompletely revoked credential, and 40 minutes.

The part that should worry you more than the breach itself

The breach is a supply-chain story security teams have heard variations of before. What happened next is the part that should actually change how you think about your own program.

After the breach went public, Beaumont told one of the largest affected companies that its credentials had been exposed. The company told him it had already rotated everything and called it "a nothing burger." Its own responsible disclosure policy allowed him to test that claim, so he did: he tried the leaked credentials against the company's live environment. Almost all of them still worked.

Read that sequence again. A well-resourced organization had a credential rotation process. Someone almost certainly recorded that the process was followed. It wasn't true, and nothing in that process was built to catch that it wasn't true until an outside researcher decided to check by hand.

That's twice in one incident. Trivy's maintainers rotated a token and believed the job was done. It wasn't fully revoked, and that gap gave Team PCP three more weeks. A downstream victim said its credentials were rotated. They weren't, and that gap is why Beaumont's test worked. Same failure, two different companies, one breach.

Identity governance answers a different question than the one that mattered here

Most enterprises already run identity programs: IAM, IGA, PAM, quarterly access reviews, attestations signed off in a portal somewhere. None of that was absent at either company. It answered a different question than the one this breach actually asked.

Identity governance is built to answer who is allowed to access what, and whether the right person signed off on it. That's an audit question, and it's worth answering. Exposure management asks something else: which of these credentials can actually be used right now, by whom, to reach what, and has anyone confirmed that's still true since the last time anyone checked. Almost nothing in a standard identity stack answers that second question continuously. Most of it answers the first question once a quarter and calls the file closed.

Vulnerability management went through this exact split years ago. A critical CVE used to be treated as handled once a ticket said "remediated." The industry learned, expensively, that a closed ticket is a claim, not a fact, which is part of why exposure validation, actually confirming a fix took, has become one of the more consequential shifts in the discipline. Identity hasn't made that same adjustment at scale. A credential marked "rotated," an account marked "disabled," an access review marked "approved": these still get treated as facts instead of claims worth checking. Beaumont checked one. A Fortune 500 company failed it.

Non-human identity makes this structurally worse, and it's the part growing fastest

The identity category growing fastest in most enterprises is also the one almost nobody reviews. GitGuardian's 2026 State of Secrets Sprawl report puts the ratio of non-human to human identities in the average enterprise at 80 to 1, and found machine credentials expanding 1.6 times faster than the developer population that creates them. SpyCloud's 2026 Identity Exposure Report found 18.1 million exposed API keys and machine credentials in circulation this year, 6.2 million of them tied specifically to AI tools.

A service account or API key doesn't have MFA to bypass. It rarely expires on its own. It usually carries broader permissions than anyone remembers granting, because it was scoped once, worked, and nobody revisited it. LiteLLM's entire value proposition is a preview of why this keeps growing: to act as a single gateway across more than 100 AI providers, it has to hold every credential to every one of those providers on your team's behalf. Every AI proxy, every orchestration tool, every pipeline that talks to more than one system, earns your trust the same way, by collecting credentials, and every credential it collects is something an attacker only has to compromise once.

Treat identity as an asset class, not a separate program

Brinqa's argument about exposure management has always been that scattered signals about what's true in your environment are worth less than one place that knows what's true right now, connected to what those assets can actually reach. Identity fits that argument without much translation. A stale, over-permissioned, unrotated credential is exposure. It belongs in the same graph as your vulnerabilities and your assets, not filed under a separate identity program with separate owners who never get asked what a CVE is.

That data is already flowing in from more places than most security teams realize: the directory layer (Active Directory, Okta, LDAP, SCIM), cloud entitlements (Amazon IAM and IAM Access Analyzer, CloudKnox, now part of Microsoft Entra Permissions Management), attack-path mapping for what a compromised account could actually reach (BloodHound Enterprise), SaaS identity posture (Adaptive Shield, Obsidian Security), privileged access and secrets (BeyondTrust Password Safe), and, increasingly relevant after a breach like this one, tools built specifically to track non-human identity and secrets sprawl (Entro). None of that is a hypothetical bolt-on. It's data that can already sit in the same risk graph as the rest of your exposure surface, which means an unrotated service account with admin access to a crown-jewel asset doesn't need a special project to surface. It shows up the way an unpatched, internet-facing critical vulnerability does: scored, owned, and tracked until it's actually fixed, not until someone says it is.

The schema already assumes attestation and reality can disagree. In Brinqa, an account carries a last-login timestamp, a last-password-change timestamp, whether it grants admin or privileged access, whether MFA is supported, and, separately, whether MFA is actually used, right alongside its own risk score and an owner. That gap between supports and uses is the same gap Beaumont exploited with a testing policy and a phone call. Most identity programs still don't track it.

What to actually do about it

Start by inventorying non-human identities the way you inventory assets, not the way you inventory policy exceptions. Every service account, API key, and machine credential needs an owner, a last-used date, and a scope on record, the same three facts you'd insist on for a server.

Stop logging rotation as an event and start verifying it as a state. A ticket that says a credential was rotated is a claim. A live check against that credential is a fact, and the gap between the two is exactly what took down Trivy's own defenses and made a Fortune 500 company's denial false.

Score identity risk with the same business context you already use for vulnerabilities. An unrotated key that can reach a crown-jewel asset is not the same problem as a stale login on a retired test box, and your identity program should be able to tell you which is which without a special project every time someone asks.

The question worth asking

Team PCP didn't need a zero-day. It needed one dependency everyone trusted, one credential nobody was watching closely enough, and 40 minutes. NVIDIA, Cisco, AWS, and roughly 2,500 other organizations found that out this year, several of them twice, since even the incident response ran into the same gap that caused the breach. The uncomfortable question isn't whether your identity program would have caught it. It's whether you'd know, right now, without asking anyone to check by hand.

FAQs