Agent skills are already a supply-chain problem

Agent skills look lightweight. Many are simply a folder of instructions and a few helper scripts. But once an agent loads one, those files can shape its decisions, read local data, run code, and influence whether the user sees a warning.

That makes installing a skill a security decision, not just a productivity shortcut.

Research presented at USENIX Security 2026 gives that concern a useful evidence base. The researchers found malicious skills in public community registries, and they found that the dangerous behavior did not live only in executable code. Some of it was written into the natural-language instructions the agent was expected to trust.

What the researchers found

The team collected 98,380 skills from two community-maintained registries in January 2026. Static analysis narrowed that collection to 4,287 suspicious candidates. The researchers then ran those candidates in isolated containers with network and system-call monitoring, filesystem auditing, and synthetic credentials designed to reveal attempted theft.

After behavioral verification and manual review, they confirmed 157 malicious skills containing 632 labeled vulnerabilities across 13 attack techniques. The confirmed skills averaged just over four vulnerabilities each and typically crossed several phases of an attack.

Two patterns stood out. One group used code and remote execution to find and steal credentials. Another manipulated the agent through adversarial instructions in skill documentation. A single actor accounted for 54.1% of the confirmed skills, using repeated brand impersonation at scale.

The numbers need careful framing. The study examined a January snapshot of two public registries. It did not cover private enterprise libraries, direct sharing, official curated collections, or MCP servers. Its 157 confirmed cases are not an estimate of how common malicious skills are across every agent environment. The researchers deliberately favored high-confidence behavioral evidence, which means the confirmed set is better understood as a lower bound.

There is encouraging news too: after responsible disclosure, the registry maintainers removed all 157 reported skills. Fast removal matters. It does not undo the trust decision already made by anyone who installed one.

Why prose changes the threat model

Traditional software review teaches us to inspect executable code, dependencies, install scripts, and network behavior. Agent skills add another privileged layer: ordinary language that can influence how the agent interprets every step that follows.

A malicious instruction may tell the agent to ignore conflicting guidance, conceal an action, prefer an unexpected tool, or treat a hidden capability as normal. None of those directives needs to look like malware to a conventional code scanner. They can be short, grammatical, and placed exactly where the agent expects trusted operating guidance.

This does not make every surprising instruction malicious. Skills often need specific workflows and permissions to be useful. The important distinction is between the capability a skill advertises and the authority it actually receives. When those drift apart, a helpful extension can become a quiet control path.

What operators should examine now

Start with provenance. Keep an inventory of each installed skill, its source repository, publisher, version or commit, review owner, requested permissions, bundled scripts, hooks, and expected network destinations. A familiar name or a polished description is not provenance.

Review the whole package. Compare the natural-language instructions, metadata, and helper code with the behavior the skill claims to provide. Look for instructions that suppress user visibility, broaden authority, fetch changing remote content, or introduce capabilities the public description never mentions.

Then separate installation from authority. An untrusted skill should not automatically inherit every credential, file, tool, and network path available to the person running the agent. Give it the smallest useful envelope, prefer short-lived and task-scoped access, and require fresh review before a material version or permission change expands that envelope.

Test uncertain packages somewhere they cannot hurt real work. Use synthetic credentials, constrained egress, and observable execution to learn which files, processes, endpoints, and tools the skill actually touches. Static scanning is a useful first pass; the study's own funnel shows why it is not the finish line.

Finally, plan for removal. Teams should be able to identify where a skill is installed, revoke the authority it used, preserve relevant action records, check for persistence, and replace or quarantine it without reconstructing the whole environment from memory.

The PrivacyFirst view

An agent skill should earn trust twice: once for what it says, and again for what it can do.

The goal is not to close the door on shared skills. It is to make their authority visible, testable, and revocable. A small file can still carry a large decision surface, and the lighter the package looks, the easier it is to grant more trust than anyone intended.