The AI Agent Credential Heist: How TeamPCP Weaponized LiteLLM to Loot Cloud Environments

On March 24, 2026, at roughly 11:47 AM UTC, an attacker published two versions of the LiteLLM Python package — versions 1.82.7 and 1.82.8 — carrying a fully operational, multi-stage credential stealer. For three hours, before PyPI quarantined the package, those versions were available to every automated build pipeline, Docker container, and CI/CD workflow that ran pip install litellm. LiteLLM is downloaded 3.4 million times per day and is present in 36% of cloud environments globally (Sonatype, 2026). The math is not comforting.

This wasn't opportunistic. It was the third strike in a methodical five-day campaign by a threat group called TeamPCP, who first compromised Aqua Security's Trivy container scanner (March 19), then Checkmarx's AST GitHub Actions (March 21), and finally LiteLLM itself (March 24) — each time using credentials stolen in the prior compromise to pivot to the next, higher-value target. The credential chain that began with a single stolen PyPI token ended inside cloud environments running production AI workloads.

The stolen-data catalog isn't subtle: AWS IAM credentials, GCP service account keys, Azure tenant tokens, Kubernetes kubeconfig files, CI/CD pipeline secrets (GitHub Actions, GitLab CI), Docker registry credentials, database connection strings, OpenAI and Anthropic API keys, and cryptocurrency wallet keys. In one exfiltration payload reviewed by Sonatype researchers, a single compromised LiteLLM instance yielded 47 unique credential artifacts across six cloud providers.

I spend most of my week chasing stolen tokens through cloud audit logs, and the question that keeps me up isn't whether your AI stack was exposed. It's this: when those credentials get used, will you know?

---

The AI Agent Stack Is the New Credential Goldmine

The security industry has spent years hardening the application layer — patching CVEs within SLAs, deploying EDR on every endpoint, layering MFA across user-facing systems. What it largely hasn't done is treat AI agent infrastructure as a security boundary.

LiteLLM, Langflow, CrewAI, AutoGen — these aren't toy frameworks. They're production middleware sitting between your applications and every major cloud API, database, and LLM provider. They're configured with real credentials. They run with real permissions. And they're often deployed with the same trust assumptions as internal tooling, which is to say almost none.

TeamPCP exploited this blind spot with mechanical precision. By poisoning Trivy — a widely trusted container security scanner embedded in thousands of CI/CD pipelines — they turned the security toolchain itself into a credential harvesting network. When LiteLLM's maintainers ran their own CI/CD build on March 24, Trivy executed its malicious payload, extracted the PyPI publishing token from the build environment, and uploaded it to an attacker-controlled relay within 90 seconds of job start (ReversingLabs, 2026). We've seen this trust-chain abuse before, and it's the core argument in our piece on why supply chain attacks demand honeytokens.

The broader context makes this worse. Just one week earlier, on March 17, 2026, CVE-2026-33017 was disclosed — an unauthenticated remote code execution vulnerability in Langflow, the visual AI pipeline builder. Sysdig's Threat Research Team recorded active exploitation within 20 hours of disclosure, with attackers specifically targeting the LLM API keys and cloud service credentials stored in Langflow's environment configuration. In one observed incident, a compromised Langflow instance yielded an OpenAI API key that was immediately used to generate $18,400 in inference charges before revocation, and an AWS access key that granted read access to 14 S3 buckets before the key was rotated (Sysdig, 2026).

Two separate threat actors, two separate attack chains, both aimed at the same surface: the AI agent credential store.

---

Why Traditional Tools Miss the Post-Theft Movement

Here's the failure mode that matters most. The TeamPCP credential stealer lived in the PyPI ecosystem for three hours. Automated build systems don't wait. Dependency update bots — Dependabot, Renovate, custom scripts — often run on schedules measured in minutes, not hours. By the time PyPI quarantined the package, thousands of build environments had already executed the malicious code and exfiltrated their credential stores.

Your SIEM saw nothing unusual. The malicious code ran inside a legitimate build process, making outbound HTTPS requests to a domain registered 72 hours earlier — a pattern indistinguishable from normal package installation telemetry. Your EDR didn't fire. The stealer operated entirely in userspace, reading environment variables and config files through standard Python file I/O. No process injection, no kernel calls, no behavioral patterns that signature-based detection recognizes.

Your cloud provider's threat detection — AWS GuardDuty, Azure Defender for Cloud, GCP Security Command Center — does log API activity. But consider the detection-latency problem: GuardDuty's anomaly detection for credential abuse typically needs 3–7 days of baseline behavior before it can distinguish legitimate API calls from an attacker using stolen long-term credentials that have never been used before. If an attacker exfiltrates an AWS key that your CI/CD pipeline generates fresh for each run and never reuses, GuardDuty has no baseline to compare against.

The rotation advice is correct but incomplete. Rotating credentials after a known compromise is necessary. It isn't sufficient. In the 72 hours between the initial Trivy compromise (March 19) and the LiteLLM quarantine (March 24), attackers had five days of active, undetected access to credentials from every build pipeline that used both tools. Some of those credentials haven't been identified as compromised yet, because the organizations don't know they were exposed.

Traditional security operates on known-bad. Supply chain attacks succeed by being unknown-bad — using legitimate credentials, through legitimate channels, to do things that look legitimate until they don't.

---

How Cloud Mines and Credential Mines Catch It

Mine2's deception technology runs on a different principle: if an attacker touches a mine, you know it — with zero false positives, no matter whether the credential they used was "known-bad."

Cloud Mines: the AWS tripwire network

Cloud Mines are fake AWS resources — S3 buckets with enticing names, IAM roles with high-sounding permissions, Lambda functions, DynamoDB tables, EC2 instances — deployed alongside your real infrastructure and configured to look exactly like production assets. They have no legitimate use. No internal system calls them. No automation references them.

When a threat actor uses a stolen AWS IAM key — whether exfiltrated by TeamPCP's LiteLLM stealer or obtained any other way — their first action is reconnaissance: ListBuckets, DescribeInstances, ListRoles. These enumeration API calls hit real resources and fake ones alike. The moment a Cloud Mine is accessed, Mine2 fires an alert with the full API call context, the IAM identity used, the source IP, and the exact timestamp.

This is not anomaly detection. No baseline required. No machine learning model to tune. An alert from a Cloud Mine means, by definition, that someone is using credentials to probe infrastructure they shouldn't. The attacker using TeamPCP's stolen AWS keys hits Cloud Mines during the first reconnaissance sweep — before they've exfiltrated a single byte of real data, before they've pivoted to any real resource.

Detection happens at the earliest possible point in the kill chain: the first post-theft API call.

Credential Mines: the decoy key store

Credential Mines are fake credentials — API keys, bearer tokens, database connection strings, cloud access keys — placed where real credentials live: .env files, Kubernetes secrets, CI/CD environment variables, application configuration stores. They look exactly like real credentials. They're formatted correctly. They pass regex validation. They don't work.

In an AI agent environment, Credential Mines show up as fake OpenAI API keys, fake AWS keys in LiteLLM's configuration, fake Anthropic API tokens in Langflow's settings — sitting next to the real ones, indistinguishable to any automated exfiltration tool. When TeamPCP's stealer harvests the environment variables and config files of a compromised LiteLLM instance, it vacuums up real credentials and Credential Mines alike. This is the same non-human-identity exposure we explore in our coverage of honeytokens for API keys and NHIs.

The moment an attacker tries to use a Credential Mine — calling the OpenAI API, making an AWS API call, authenticating to a database — Mine2 records the attempt, the source, the target service, and the exact credential used. The attacker gets an authentication failure. You get a high-fidelity alert telling you which credential was stolen, which attacker IP tried to use it, and which service they were targeting.

MineField: the lateral movement sensor network

After credential theft comes lateral movement. Attackers with valid cloud credentials don't stop at enumeration — they probe for open services, scan for internal endpoints, and try to reach adjacent systems. MineField deploys decoy TCP services across your network — fake SSH servers, fake database listeners, fake API endpoints — that exist solely to catch this scanning.

In a cloud environment compromised via stolen LiteLLM credentials, an attacker reaching for internal services will inevitably hit MineField nodes. Detection is immediate and connection-level, and it produces actionable forensics: the source IP, the service being probed, and the timing of each probe. Paired with Cloud Mine alerts from the same attacker IP, MineField gives you corroborating evidence that establishes the full lateral movement timeline.

The zero false positive guarantee

Every alert from Mine2's deception layer is a confirmed hostile action. No real user, no legitimate automation, no misconfigured system will ever trigger a Cloud Mine, use a Credential Mine, or probe a MineField service. Security teams get high-fidelity alerts that require action, not noise that requires triage. In the aftermath of a supply chain compromise like TeamPCP's, where the scope of credential theft may not be clear for days, Mine2's deception layer keeps watching and catches attacker activity regardless of which specific credential they're using.

---

Breach Detection Speed Is Now a Legal Obligation

The TeamPCP campaign isn't just a security incident. For any organization with exposed credentials that the attacker used, it's a notifiable breach under multiple regulatory frameworks — and the reporting clock started the moment the attacker made their first API call with stolen credentials.

CERT-In 6-Hour Reporting: India's CERT-In cybersecurity directive requires organizations to report cybersecurity incidents — including unauthorized access to cloud systems — within 6 hours of detection. The operative word is detection. An organization whose cloud credentials were exfiltrated on March 19 but whose first Cloud Mine alert fires on March 26 has a 7-day detection gap it can't explain to regulators. Mine2's real-time alerting provides the documented detection timestamp that starts the compliance clock accurately.

GDPR Articles 33 and 34: Under GDPR, a personal data breach must be reported to supervisory authorities within 72 hours of becoming aware of it (Article 33). If the breach involves high risk to individuals, affected parties must be notified without undue delay (Article 34). For organizations processing EU personal data through AI agent pipelines — a common pattern in SaaS applications — any credential theft that could enable unauthorized access to personal data triggers these obligations. Mine2's deception layer provides the audit trail documenting when awareness occurred, what was accessed, and what data was at risk.

India DPDP Act: The Digital Personal Data Protection Act requires Data Fiduciaries to notify the Data Protection Board of India upon breach of personal data. Cloud credential theft that exposes environments containing personal data is a qualifying breach. The Mine2 audit trail provides the incident timeline documentation required for regulatory submissions.

PCI-DSS Requirement 11: PCI-DSS v4.0 Requirement 11.5 mandates unauthorized access detection and alerting for cardholder data environments. Cloud Mines deployed in AWS environments handling payment data provide continuous, automated detection coverage that satisfies this requirement with documented, timestamped alerts.

RBI and SEBI Directives: The Reserve Bank of India's cybersecurity framework for banks and the Securities and Exchange Board of India's cybersecurity circular both require immediate incident reporting for cyber incidents involving unauthorized access. Financial institutions using AI agent frameworks in trading systems, fraud detection pipelines, or customer data processing have a specific obligation to detect and report credential-based access events — exactly the scenario TeamPCP's attack creates.

HIPAA Breach Notification Rule: Healthcare organizations running AI-assisted diagnostics, clinical decision support, or administrative automation on infrastructure that uses LiteLLM or similar frameworks face HIPAA breach notification obligations if protected health information was accessible via compromised credentials. Mine2's Cloud Mines provide the forensic evidence needed to determine whether PHI was accessed — critical for establishing whether a breach is notifiable or falls under safe harbor.

---

A Practitioner's Playbook for AI Agent Infrastructure

These steps address both immediate response to the TeamPCP campaign and longer-term hardening of AI agent environments with a deception-first approach.

Step 1: Immediate credential audit (24 hours). Run a dependency audit across all Python environments to find out whether LiteLLM versions 1.82.7 or 1.82.8 were installed between March 24 and March 27, 2026. Check build logs, Docker layer histories, and pip audit outputs. For any environment that executed these versions, treat all accessible credentials as compromised and rotate immediately.

Step 2: Deploy Credential Mines in AI environment configuration. Before you deploy the next version of your AI agent stack, seed the environment with Mine2 Credential Mines — fake API keys formatted to pass validation checks for OpenAI, Anthropic, AWS, and other services configured in your LiteLLM or Langflow instances. These mines travel with any future exfiltration attempt and notify you immediately when stolen credentials are used. Deployment is a single click through Mine2's console and requires no changes to production application code.

Step 3: Activate Cloud Mines in all cloud environments. Deploy Cloud Mines as decoy resources in every cloud account that uses AI agent services. Focus on S3 buckets that match your production naming conventions, IAM roles with names like LiteLLMServiceRole-prod, and Lambda functions named for common AI agent patterns. These specifically draw attackers who've stolen AI-stack-adjacent credentials and are doing cloud reconnaissance.

Step 4: Instrument MineField on internal AI service ports. AI agent frameworks often run on predictable internal ports (LiteLLM defaults: 4000, Langflow defaults: 7860). Deploy MineField on these ports in adjacent subnets and on non-production segments. An attacker performing lateral movement after cloud credential theft will scan for these services, and MineField catches them before they reach production.

Step 5: Tighten non-human identity hygiene. Work toward eliminating long-lived static API keys in AI agent configurations. Use IAM roles with instance profiles instead of access keys in AWS. Use Workload Identity Federation in GCP. Use Azure Managed Identities. Where static keys are unavoidable, deploy Mine2 Credential Mines alongside them — the mines are the detection layer for the keys you can't yet rotate. The same logic carries straight over to SaaS-to-SaaS integrations, as we detail in our analysis of SaaS integration token theft.

Step 6: Build a deception-first incident response playbook. Pre-configure automated response actions triggered by Mine2 alerts: a Cloud Mine alert triggers credential revocation for the IAM identity that accessed it; a Credential Mine alert triggers an investigation workflow in your SIEM; a MineField alert triggers network isolation of the source IP. Mine2 alerts carry the specificity needed to automate these responses without false positive risk.

---

The Signal That Cuts Through the Noise

The industry will respond to the TeamPCP LiteLLM attack with the standard prescription: patch faster, rotate credentials more often, implement software composition analysis, run dependency audits. All correct. None of it sufficient.

Supply chain attacks succeed because they weaponize trust. The LiteLLM package was trusted. The Trivy scanner was trusted. The CI/CD pipeline that ran both was trusted. Credentials exfiltrated through this trust chain are real credentials — and when an attacker uses them, they look like legitimate API calls from legitimate services.

The only detection definitionally immune to this legitimacy problem is deception. Cloud Mines don't care whether the IAM key is flagged "known-bad" in any threat feed. Credential Mines don't need behavioral baselines. MineField doesn't have to distinguish legitimate scanning from malicious scanning, because legitimate systems never scan it at all.

When TeamPCP's stolen credentials are used to probe your cloud environment, Mine2 will know. The only question is whether you deployed the mines before the attacker showed up.

Protect your AI agent infrastructure with Mine2's deception layer — zero false positives, single-click deployment, zero performance impact. Deploy Mine2 in your environment today →