Skip to main content
Agent Skills are small packages bundling Markdown instruction files and a few scripts, but they run with the same privileges as the agent itself. They can reach file reads and writes, shell execution, and every stored credential, which makes them in substance executable packages with a supply chain attack surface at least as large as npm’s or PyPI’s.

​
Risk scenarios

Attacks through skills take three main routes.
  • A skill that is malicious from the start gets distributed through a marketplace or GitHub
  • A legitimate skill is compromised later and turns malicious through an update
  • The skill itself is harmless, but instructions are injected through external data it loads at runtime
All of them run with the agent’s privileges, so the damage extends to credential theft, source code exfiltration, and backdoor installation. What makes this troublesome is that some skills look clean when reviewed or scanned and turn malicious the moment they actually run. A notice that a skill passed a static scan is a starting point, not a guarantee of safety.

​
Supply chain risks

Community-developed skills call for particular caution. When controls like branch protection are missing, or when a developer’s personal account is compromised, the contents can be tampered with while the distribution channel stays legitimate. From the user’s side it looks like a legitimate update from a trusted source, and at the moment of adoption there is no reason to be suspicious. This pattern is not unique to skills. The same incidents have played out in package managers like npm and pip, in extensions for code editors like Visual Studio Code, and in browser extensions for Google Chrome. Skills are young enough that standards for signing and provenance verification haven’t settled, which makes the same mistakes easy to repeat.

​
Attacks that persist

When skills ship as Claude Code plugins, auto-update is on by default. Combined with a rug pull attack that rewrites the contents after approval, this means you keep using a compromised skill for a long time without noticing. And if you don’t know which version you’ve been running since when, you can’t determine your organization’s exposure even after a compromise is disclosed.

​
npx skills and lock files

The npx skills command used in the standalone skill ecosystem now generates a lock file when downloading a skill and can enforce pinning to a specific version. Making the version in use visible through pinning is real progress. Manage the skills under a project and push the repository to GitHub with the lock file included, and you can trace a compromise through history and diffs, whereas installing them in a user’s home directory leaves no change history, so working out after the fact what was swapped and when becomes difficult. And pinning only covers the skill package itself. Note that documentation the skill loads from an external URL at runtime can still be rewritten.

​
Monitoring and alert response

Who is using which version of which skill, and where. Managing this as a regularly synchronized inventory is the foundation of monitoring. Manage employee endpoints with MDM, and periodically collect, parse, and inventory the configuration files sitting on local disks. Alongside the inventory, set up multiple channels for staying current on skill compromises and prepare a response process. Once a compromise is disclosed, the work is identifying affected versions, finding the devices that use them, disabling the skill, and rotating credentials. Hash each skill at installation and hash it again before execution, and the comparison also catches auto-updates and later rewrites.

​
Visibility and centralization as prevention

A low-cost way to start is a private fork, after checking the license. Make the internal fork the sole distribution source and use only it across the organization. Versions stay pinned, and every external update passes review as it’s pulled into the fork. Malicious skills and compromised updates can be caught at the pre-fork review stage, stopping the damage before it happens.

​
Vetting skills with scanning tools

Established security vendors publish open source scanners that detect malicious instructions and scripts. Cisco AI Defense’s skill-scanner inspects a skill directory you point it at, layering YARA-based static analysis, behavioral analysis of AST dataflows, LLM-based semantic analysis, and VirusTotal lookups to catch prompt injection, data exfiltration, and malicious code. It ships with a GitHub Actions workflow and SARIF output, so the review that runs when you pull updates into a private fork can be automated as CI. Snyk’s Agent Scan comes at the problem from the other side, starting from the endpoint. It automatically discovers configurations for Claude Code, Cursor, and other agents, enumerates the installed skills, MCP servers, and agent configurations, and checks them for more than 15 kinds of risk including prompt injection, malware, and hardcoded secrets. Because it inventories and scans a machine whose contents you don’t know in a single pass, it also serves as an entry point for building your inventory. Neither scanner is a silver bullet, though. Instructions written purely in natural language carry no code signature, encoded payloads slip through, and a skill can technically serve harmless content to the scanner while affecting only the live agent.

​
References