Last week, your security scanner may have been working against you.
On March 24, Socket Research published a detailed attribution report naming TeamPCP — a coordinated threat actor responsible for both the Trivy GitHub Actions tag compromise and the LiteLLM PyPI supply chain attack. The pattern is precise and disturbing: target the security tools themselves. Turn the scanner into the infostealer.
If you used LiteLLM v1.82.7 or v1.82.8 in an AI agent environment, your SSH keys, API keys, environment variables, AWS/GCP credentials, crypto wallets, and SSL private keys may have been exfiltrated. The payload activated on Python startup via a .pth file — no explicit import required. Mandiant is engaged. The packages remain pulled.
This isn't a LiteLLM failure. It's a supply chain architecture problem. And it has direct implications for how you should think about AI agent security tooling.
The TeamPCP Pattern: Compromising the Defender
TeamPCP's playbook has two confirmed chapters:
Chapter 1 — Trivy (GitHub Actions). Trivy is one of the most widely-used container and dependency scanners. TeamPCP compromised a Trivy-adjacent GitHub Actions tag, injecting malicious steps into workflows that ran the tag. Developers who pinned to the tag instead of a commit SHA got the payload. Their CI pipeline — the thing meant to catch malicious code — became the delivery mechanism.
Chapter 2 — LiteLLM (PyPI). LiteLLM is a popular Python wrapper for calling LLM APIs. TeamPCP hijacked the PyPI account and published two poisoned releases. Any environment that ran pip install litellm and got v1.82.7 or v1.82.8 was compromised at import time. AI agents running LiteLLM for routing or orchestration would have silently exfiltrated their full credential surface on startup.
The common thread: the defender became the attacker. The security tool became the delivery vector. The CI step became the payload.
Why Your CI Scanner Can't Solve This
The instinct after a supply chain attack is to add more scanning. Run OWASP Dependency Check. Install Snyk as a GitHub Action. Add Trivy to your pipeline.
But TeamPCP has already demonstrated the problem with this instinct: if the scanner lives inside your supply chain — as a PyPI package, a GitHub Actions tag, a CI plugin — it is subject to the same class of attack it's meant to detect.
A compromised scanner doesn't just fail to catch malicious packages. It actively benefits the attacker: it runs with the same elevated permissions as your CI environment, has access to the secrets your pipeline uses, and produces a clean report that gives you false confidence.
This is not a theoretical concern. TeamPCP did it, at scale, against security infrastructure.
The Architectural Argument for External Scanning
SkillShield takes a different approach: it operates outside your supply chain.
SkillShield is not a PyPI dependency you install into your agent environment. It is not a GitHub Actions tag you pin in your workflow. It doesn't run inside the same Python process as your LiteLLM integration or your MCP skill loader.
This matters because it means SkillShield cannot be TeamPCP'd.
TeamPCP's attack requires that you've pulled the compromised package or tag into your execution environment. SkillShield scans skills and packages before installation — at the point of decision, not the point of execution. An attacker who compromises a skill on ClawHub or a package in your agent's dependency chain still gets flagged before it runs.
Here's what that looks like in practice:
- You want to add a new OpenClaw skill to your agent.
- SkillShield scans it against known-malicious patterns, behavioral indicators, credential harvesting signatures, and supply chain provenance checks — before you install it.
- If it's clean, you install. If it isn't, you get a report with the specific indicators.
- SkillShield never runs inside your production agent environment. It never touches your API keys. It has no access to your credentials.
Compare that to a scanner that ships as a PyPI package and runs inside your agent's Python process. That scanner has access to everything your agent has access to — including the credentials you're trying to protect.
What the 31,000 ClawHub Audit Showed
Earlier this week, we reported that an independent audit of 31,000 ClawHub skills found 7.6% were dangerous or malicious — roughly 2,371 skills that would exfiltrate credentials, inject prompts, or establish persistence in your agent environment.
TeamPCP's attack adds a new dimension to that number: the threat isn't just malicious skills installed by unsuspecting users. It's malicious packages inserted into the dependency chains of legitimate-looking skills. A skill can be clean at the SKILL.md level but pull a compromised PyPI dependency on install.
SkillShield's dependency chain analysis catches exactly this: it doesn't just scan the skill manifest, it traces the dependency graph and flags packages with known supply chain compromise indicators.
The OpenClaw GHSA Blind Spot
There's a compounding factor worth flagging. OpenClaw has filed 255 GitHub Security Advisories (GHSAs) in approximately three weeks. GHSAs are the upstream signal for supply chain risk — but research from Fluminense Federal University shows that only ~8% of GHSAs ever receive CVE assignment.
Enterprise patch management, SBOM tools, and most CI scanners operate primarily on CVE databases. That means 92% of OpenClaw GHSAs — including any that cover TeamPCP-adjacent supply chain issues — are invisible to the tools most teams rely on.
SkillShield's threat intelligence covers GHSA directly, not only CVE. That's not a marketing claim — it's a structural difference in what gets flagged.
What to Do Now
If you ran LiteLLM in an agent environment between March 20–25, treat your credentials as compromised. Rotate API keys, SSH keys, and any environment variables that were accessible in that Python process. Mandiant's engagement is ongoing; full IOC list is available at the LiteLLM GitHub issue.
For your ongoing agent security posture:
- Audit your dependency graph, not just your skill manifests. Tools that run inside your agent's Python process (security scanners included) share its credential access.
- Prefer external scanning at install time over in-process scanning at runtime.
- Pin to commit SHAs, not tags, for any GitHub Actions in your workflow.
- Verify GHSA coverage in any scanner you use — CVE-only coverage misses the majority of upstream supply chain signals.
- Run SkillShield before installing any new skill, especially those with external package dependencies.
The Structural Lesson
TeamPCP didn't find a vulnerability in LiteLLM's code. They found a vulnerability in the trust model: developers trust the packages they install, and they trust their security tools especially. Compromising the security tool is the highest-leverage attack because it simultaneously delivers the payload and suppresses the alert.
The answer isn't to stop using security tools. It's to use security tools that are architecturally outside the attack surface they protect.
That's the design principle behind SkillShield. External scanners that don't live in your supply chain cannot be turned against you by actors who target your supply chain.
Sources: Socket Research — TeamPCP attribution (March 24, 2026), LiteLLM GitHub Issue #24518, HN: TeamPCP thread (853 points), Socket — OpenClaw GHSA surge, Fluminense Federal University GHSA study.