Slopsquatting and the New AI Supply Chain Attack Surface

The TeamPCP campaign in March 2026 used a stolen token to cascade across five ecosystems in eight days, publishing backdoored LiteLLM versions 1.82.7 and 1.82.8 on PyPI that swept LLM API keys, cloud credentials, and Kubernetes tokens, putting downstream keys at risk. Slopsquatting, the squatting on package names AI assistants hallucinate, is one entry point, with studies finding fabricated-package rates between 4.6% and 21.7% depending on the model, and a 2026 replication found 127 names all five frontier models invent identically, 53 of which an attacker could still register. The OWASP Agentic Top 10 for 2026, released in December 2025, names Human-Agent Trust Exploitation and agentic supply-chain vulnerabilities as key risks for AI-assisted coding, noting users approve 97% of agent permission prompts and reject only 3%.

AI coding tools no longer just autocomplete the code you’re writing. They scaffold projects, pick dependencies, and install packages on your behalf, with minimal human oversight. You review the output, but not the supply chain /ai-coding-tools-faster-shipping-harder-testing-new-vulnerabilities behind it. Attackers have noticed. The TeamPCP https://attack.mitre.org/groups/G1056/ campaign made this real. In March 2026, one stolen token cascaded across five ecosystems in eight days https://a16z.com/et-tu-agent-did-you-install-the-backdoor/ , ending with backdoored LiteLLM https://www.litellm.ai/ versions on PyPI. LiteLLM is an AI gateway holding API keys for dozens of providers, so one package turning malicious at the source put downstream keys at risk. Slopsquatting https://en.wikipedia.org/wiki/Slopsquatting is one entry point; the LiteLLM compromise shows the same supply chain under attack through a different door. The vocabulary that names it: slopsquatting, the OWASP Agentic Top 10, MLSecOps https://mlsecops.com/ , and agentic governance. What is slopsquatting, and how did the TeamPCP campaign compromise LiteLLM? Slopsquatting is squatting on the package names AI assistants hallucinate https://www.kusari.dev/blog/ai-coding-assistants-in-2026-4x-faster-10x-riskier-the-hidden-security-cost . Code models invent plausible but non-existent names, and attackers pre-register those names with malicious code and wait for an agent to install. Unlike typosquatting, which leans on human typos, slopsquatting exploits a machine’s inference error at machine speed. The enabling mechanism is LLM package hallucination. Studies put fabricated-package rates between 4.6% and 21.7% depending on the model https://safedep.io/ai-native-sdlc-supply-chain-threat-model , and a 2026 replication https://arxiv.org/abs/2605.17062 found 127 names all five frontier models invent identically, 53 of which an attacker could still register. Agents like Claude Code, Cursor, and Codex then act on those names, with no way to verify legitimacy /why-ai-coding-tools-ship-faster-but-fail-more-security-tests . TeamPCP walked through a different door. Attackers used credentials harvested from LiteLLM’s own CI/CD pipeline https://securitylabs.datadoghq.com/articles/litellm-compromised-pypi-teampcp-supply-chain-campaign/ to publish backdoored versions 1.82.7 and 1.82.8 https://unit42.paloaltonetworks.com/teampcp-supply-chain-attacks/ to PyPI. Version 1.82.8 shipped a .pth file that ran on every interpreter start, sweeping LLM API keys, cloud credentials, and Kubernetes tokens from a library whose job is holding keys for dozens of providers. LiteLLM sees around 95 million downloads a month https://www.strikegraph.com/blog/the-mercor-breach-exposed-silicon-valleys-fragile-ai-supply-chain and turns up in an estimated 36% of cloud environments. The compromised versions spread beyond anyone who knowingly adopted them https://www.trendmicro.com/en us/research/26/c/inside-litellm-supply-chain-compromise.html . LiteLLM was a real project reached through stolen tokens, so the name itself was never hallucinated. That is where the OWASP Agentic Top 10 gives the pattern a name. What is the OWASP Agentic Top 10 for 2026, and which risks apply to AI-assisted coding? The OWASP Agentic Top 10 for 2026 https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/ is the first formal taxonomy of risks from autonomous AI agents, released in December 2025 for 2026. For AI-assisted coding, two entries matter: Human-Agent Trust Exploitation and agentic supply-chain vulnerabilities. Human-Agent Trust Exploitation is the risk that people let an agent’s confident appearance stand in for verification https://goteleport.com/blog/owasp-top-10-agentic-applications/ . When agents ask for permission one prompt at a time, users approve 97% of those prompts and reject only 3% https://www.callibrity.com/articles/the-approval-placebo-what-claude-code-auto-mode-reveals-about-risk-in-ai-coding-agents . When the same tool presents a full plan for one approval, the rejection rate climbs to 39%. People scrutinise plans but rubber-stamp prompts /how-to-govern-ai-coding-tools-and-decide-where-the-fix-belongs . The supply-chain category https://aimonk.com/agentic-ai-security-governance/ is where slopsquatting fits: malicious code injected through agent frameworks, plugin registries, or tool definitions, including agents pulling unvetted dependencies into your build. The list extends the classic OWASP Top 10, which governs application flaws, while this one governs what agents do on their own. The surface is bigger than packages; it includes the models themselves. What is MLSecOps, and how does it extend DevSecOps to AI model weights? DevSecOps protects code and libraries. MLSecOps adds a layer for the machine learning lifecycle: model weights, training data, and provenance. Unlike source code, many models ship in formats that run code when loaded, which scanners cannot read. The model-weight lifecycle carries its own attack vectors. Hugging Face https://hivesecurity.gitlab.io/blog/huggingface-ai-supply-chain-attacks-2026/ hosts over a million models with open publishing, the npm of AI. Attackers use typosquatting, pickle exploits, and namespace reuse, where a deleted account name gets re-registered and a trusted model points at an attacker’s version. One fake OpenAI repository hit number one trending with 244,000 downloads in 18 hours before removal, one instance of the pattern in your model registry. The governance outcome is model provenance: knowing which weights are running, where they came from, and whether they have been tampered with. The visibility control is an AI-BOM https://www.wiz.io/academy/ai-security/ai-bom-ai-bill-of-materials , which extends the SBOM https://en.wikipedia.org/wiki/Software bill of materials idea to model weights, datasets, training provenance, and registry sources. Model provenance is one part of the answer; the control layer that ties it together is agentic governance. What is agentic governance in the software supply chain? Agentic governance is the control layer that treats AI agents as first-class, auditable actors https://checkmarx.com/blog/rsac-2026-marked-a-turning-point-for-appsec-the-reason-agentic-security/ . Four controls do the work: identity, least privilege, human-approval gates, and provenance for every action. The point is to constrain what the agent can do in the first place and shrink its blast radius. It closes the binary gap https://cloudsmith.com/blog/the-2026-guide-to-software-supply-chain-security-from-static-sboms-to-agentic-governance . Traditional tooling protects source code and compiled binaries but misses the AI-generated code and agent actions between them. You can scan every repository and still miss what an agent pulled or ran during a build. Closing that gap means provenance for agent actions. It changes the SBOM conversation. A static SBOM is a compliance snapshot; a living, operationalised SBOM is tied to build and runtime and reflects what is actually running. In 2026 the question is whether you can govern your SBOM. Agencies such as the Australian Cyber Security Centre https://www.cyber.gov.au/business-government/secure-design/artificial-intelligence/careful-adoption-of-agentic-ai now advise allow-listed tools, logged activity, and human approval for high-stakes actions. Agentic governance bridges the root cause, AI-generated code that is insecure by default, to where the fix belongs: the model, the tool, or the platform. The series hub maps the wider landscape. Conclusion The TeamPCP to LiteLLM cascade was the first documented case of a pattern the OWASP Agentic Top 10 for 2026 recognises. The security boundary has moved. The old controls guarded code and binaries; the new surface spans hallucinated dependencies, model weights, datasets, and registries. The response is a governance layer: agent identity, least privilege, human-approval gates, and provenance for every action, anchored by a living SBOM. The point of failure has moved from the repository to the agent, and the fix belongs at the governance layer. For the wider landscape, return to the hub. Frequently Asked Questions Is slopsquatting just typosquatting under a new name? No. Typosquatting relies on a human typing a slightly wrong package name, so linters and code review can often spot it. Slopsquatting exploits the names AI assistants hallucinate or invent, which are then installed by the agent itself, often with no human in the loop. The practical difference is speed and trust: slopsquatting targets a machine’s inference error, so the defence has to move from catching typos to governing agent actions. How do AI coding tools end up installing packages that don’t actually exist? Large language models sometimes generate plausible but invented package names, reported at rates around 4 to 22 per cent. Because AI coding agents such as Claude Code, Cursor, and Codex are built to act on their own output, they can attempt to install these hallucinated names without a human verifying them first. Attackers have learned to pre-register exactly those names, so the “missing” package resolves to a malicious one instead of failing. Is slopsquatting only a problem for Python and PyPI? No, the pattern is not limited to Python. The LiteLLM compromise used PyPI, but the underlying weakness is the agent’s trust decision, not the registry. Any ecosystem where AI assistants suggest package names, npm, Maven, RubyGems, or Go modules, can be gamed the same way. Slopsquatting is a supply chain tactic that travels with the coding agent, so teams should treat it as a cross-language risk rather than a Python-specific incident. How would I know if my organisation was affected by the LiteLLM compromise? Start with your dependency inventory and build records. Check whether any project pulled LiteLLM versions 1.82.7 or 1.82.8 from PyPI during the window of the TeamPCP campaign. Because the payload harvested LLM API keys, cloud credentials, and Kubernetes tokens, also rotate any keys that touched a compromised gateway. Treat this as a credential exposure event first: revoke and rotate before assuming the malicious versions were never installed. What should developers check before accepting an AI-suggested dependency? Treat every AI-suggested package as unvetted until proven otherwise. Check that the name actually exists in the registry, confirm the maintainer and publish history, and verify the version matches a real release. Look for recently created accounts, missing documentation, or a package that appeared suspiciously close to when the suggestion was generated. The most important habit is to review the supply chain behind the suggestion, not just the code the tool wrote. Does the OWASP Agentic Top 10 replace the original OWASP Top 10? No, it extends the picture rather than replacing it. The classic OWASP Top 10 still covers web application risks such as injection and broken access control. The OWASP Agentic Top 10 for 2026 adds the threats introduced by autonomous agents, including Human-Agent Trust Exploitation and agentic supply-chain entry points. Organisations need both lists: one governs traditional application flaws, the other governs what agents do on their own. What is an AI-BOM, and how is it different from a regular SBOM? An AI-BOM, or model bill of materials, extends the software bill of materials concept to AI assets. A regular SBOM lists software components and dependencies; an AI-BOM adds the model weights, datasets, training provenance, and registry sources behind a deployed model. It answers a question a code SBOM cannot: which weights are actually running, where they came from, and whether they have been tampered with. Is agentic governance just another security scanning tool? No. Agentic governance is a control layer, not a scanner. It treats AI agents as first-class, auditable actors by applying identity, least privilege, human-approval gates, and provenance to every agent action. A scanner finds problems after code exists; governance constrains what the agent can do in the first place. The goal is to shrink the agent’s blast radius and make autonomous actions accountable, which static detection alone cannot achieve. What does the “binary gap” mean in practice? The binary gap is the visibility blind spot between protected source code and compiled binaries. Traditional security tooling watches those two ends of the pipeline, but AI-generated code and the agent actions in between often go unobserved. In practice, it means an organisation can scan its repositories and still miss what an agent pulled, installed, or executed during a build. Closing that gap requires provenance for agent actions, not just more static scanning. Can a living SBOM stop a slopsquatting attack on its own? No, a living SBOM is a visibility control, not a prevention control. It tells you what is actually running and ties that inventory to build and runtime, so a malicious dependency becomes visible sooner. But it does not block the agent from installing a hallucinated package in the first place. Stopping slopsquatting still requires approval gates and identity controls; the living SBOM gives you the record you need to find and respond to the breach. Why do model weights need their own security controls? Model weights are executable artefacts with their own tampering risks. A poisoned or malicious set of weights can change model behaviour, and formats such as pickle can carry code execution during loading. Namespace reuse on registries like Hugging Face adds another route for attackers to swap trusted models. Because DevSecOps was built for code and binaries, model weights need separate integrity and provenance controls across training, registry, and serving.