The Missing Dependencies Hidden Inside AI Agent Skills and Plugins

We found 72 exported AI agent skills and plugins referencing package names that do not exist.

Across 45 repositories with a combined 69,520 GitHub stars, those missing dependencies appeared in install instructions, setup scripts, and exported agent assets spanning npm, PyPI, and Cargo.

That matters because a missing package name is not inert. It is available.

The package does not exist. That means the name is still available.

An attacker does not need to compromise the plugin, the marketplace, or the repository. They can register the missing package name and wait for the next install.

This is sometimes called slopsquatting: the supply-chain cousin of typosquatting, created by AI-generated package names instead of human spelling mistakes.

The problem is not malicious plugins. The problem is that AI-generated ecosystems increasingly contain dependencies that nobody owns yet.

Why Skills and Plugins Matter

If you already live in coding-agent land, you can skip this part. For everyone else, here is the short version.

A skill is a packaged set of instructions and resources that teaches an agent how to do a specific task well. Think: generate financial reports in a house style, fill out a PDF workflow, or review code using a team’s rules. Instead of explaining the process every time, you give the agent the skill and let it follow the playbook.

A plugin is broader. It can bundle tools, commands, integrations, workflows, and sometimes small toolchains. A plugin might connect an agent to a ticketing system, run a custom linter, inspect cloud logs, or enforce a review process.

The base agent is a strong generalist. Skills and plugins give it specialist training and sharper tools.

The way people get those tools is starting to look familiar: marketplaces. Some official, some community-run, some curated, some not. You browse, install, and suddenly your agent can do something new.

That is powerful. It is also a supply-chain surface.

Key Findings

We followed listings across claudemarketplaces.com and looked at exported plugins and skills that developers can install directly into agent workflows.

The short version:

45 repositories contained at least one missing package reference.
72 exported assets were affected: 45 standalone skills and 27 plugin-bundled skills.
69,520 combined GitHub stars were attached to the affected repositories.
50 npm, 18 PyPI, and 4 Cargo package references were missing.

While 72 affected assets is a small slice of the broader ecosystem, the pattern appeared across multiple package managers and repositories with meaningful developer visibility. This does not look like one isolated mistake in one obscure project.

How We Checked

For each exported asset, we extracted installation commands, dependency manifests, setup scripts, and README instructions. We then checked referenced package names against the appropriate public registry: npm, PyPI, or Cargo.

Packages with no registry record and no evidence of prior publication were classified as missing package references.

The scan was intentionally simple. We were looking for install paths that point to packages that do not exist. That is the part that matters for slopsquatting: if the name is unclaimed, someone else can claim it later.

The Attack Is Almost Embarrassingly Simple

Imagine a skill tells users to run:

pip install myapi-client

The package name looks reasonable. The repository appears legitimate. The skill may even be listed in a marketplace people trust.

If a name like myapi-client were still unclaimed on PyPI, it would not be harmless.

In a real vulnerable asset, that name would be available.

An attacker can register that package tomorrow. The next person who installs the skill may pull attacker-controlled code.

From there, the story becomes familiar: a malicious install script, token theft, environment scraping, source-code access, persistence, or a foothold into a company network.

The attacker did not kick the door down. The trusted plugin handed them a key.

Why Trust Does Not Fully Solve This

The obvious response is: “Fine, I will only use official plugins.”

That is a good instinct. It is not enough.

Several missing package references appeared in repositories that many developers would reasonably consider trustworthy. That is what makes this issue difficult to spot: at review time, there may be no malware to detect.

The bad package does not exist yet. The plugin can look harmless, the repository can look normal, and the marketplace listing can look clean.

The risk appears later, when someone claims the empty name.

Trusted sources still matter. They just cannot be the whole defense.

Why Agents Raise the Stakes

Developers have always copied install commands. What changes with coding agents is speed and delegation.

An agent can read setup instructions, run commands, install dependencies, wire tools together, and keep going. That is useful. It also makes it easy to stop noticing every command that crosses the terminal.

Plugins and skills are designed to make agents more capable. In practice, that often means giving them more authority: access to files, shells, secrets, cloud tools, internal docs, ticketing systems, and production-adjacent workflows.

A bad dependency in a normal developer package is already bad. A bad dependency pulled in by an agent plugin can be worse, because the agent may be operating in an environment with exactly the kind of access an attacker wants.

Responsible Disclosure

We are intentionally not publishing affected package names or repository names here. Publishing unclaimed package names would create a registration race we do not want to encourage.

We are coordinating disclosure with affected maintainers and marketplace operators so missing references can be removed, renamed, or claimed by the rightful project owners before attackers notice them.

What To Check

We are not saying “do not use plugins.” Skills and plugins are a real productivity multiplier. We use them too.

The point is simpler: treat them like code you are adding to your environment, because that is what they are.

Check every dependency a plugin installs. Make sure the package exists, has real history, and is maintained by who you think maintains it.
Pin versions and verify integrity. Names alone are not enough. Use lockfiles and hashes where your ecosystem supports them.
Read install scripts. If setup runs commands on your machine, review them like you would review a pull request.
Prefer auditable source. Opaque bundles and “just run this” installers deserve more suspicion.
Scan official plugins too. Marketplace trust is useful, but it is not a substitute for dependency verification.
Watch for plausible nonsense. A dependency name that sounds perfect but has no registry history is not harmless. It is available inventory for an attacker.

The Bottom Line

Coding agents are getting more powerful because we are connecting them to more tools. That is the whole point of plugins and skills.

Every new capability is also a new path into your environment.

Use the tools. Take the productivity win. Just do not treat plugin install instructions as magic.

Because with slopsquatting, the attack can start before the malicious package even exists.

If you find a plugin referencing a package that does not exist, report it to the maintainer before installing it. These references are easy to miss, and they create unnecessary supply-chain risk.