An AI agent skill is a packaged capability, natural language instructions plus code plus tool bindings, that tells an AI assistant how to do something specific. A plain LLM can only talk. An agent with skills can act: read a file, call an API, run a script, install a dependency. That distinction is the entire story.

A skill is not just code you can scan the way you scan a package. It's a hybrid artifact: instructions in a SKILL.md file, executable helper scripts, references to external tools and MCP servers, and runtime behavior that only appears once the agent actually uses it. Ecosystems built around tools like Claude Code, Codex, and Cursor made these skills fast to write, share, and install. Third-party marketplaces now list well over a million of them.

Why agent skills are a supply chain problem, not a feature problem

Every one of those skills crosses a trust boundary the moment a developer installs it. That's the definition of a software supply chain: code and instructions you didn't write, running with your permissions. A traditional package usually gets inspected once, mostly for its code. An agent skill has to be trusted across a longer chain: at publication, when your agent parses its metadata, when your agent decides to invoke it, and when it actually executes against your filesystem and network.

Each stage resolves at a different point in time, and no earlier stage can guarantee what a later one will do. A skill can pass a clean code review and still change behavior the next time it runs, because a remote MCP server changed its response, a dependency updated silently, or a conditional branch tied to a specific user context finally triggered.

The part scanners were never built to read

Roughly half of what makes a skill risky lives in language, not code: the instructions in SKILL.md, how a tool describes itself, metadata, IDE rule files. Conventional code scanners read source files and dependency graphs. They weren't built to read a paragraph of natural language and judge whether it's quietly instructing an agent to exfiltrate a credential.

That gap is why "was this file scanned" and "is this skill safe to run" are different questions.

Third-party marketplaces already list well over a million community-contributed agent skills, most installed with no consistent vetting process at all.

What this means for security teams

If your developers use Claude Code, Cursor, Copilot, or any agentic coding tool, agent skills are already part of your environment, whether or not they show up in an inventory today. The practical question isn't whether to allow them. It's whether you can see what's running, understand what it's built to do, and catch the ones that were never built to do what they claim.

FAQ

Is an agent skill the same as a plugin or browser extension? Not quite. A plugin usually extends an application's features or UI. An agent skill is narrower and more powerful: a set of instructions and code an AI agent reads and then acts on autonomously, often with filesystem, network, and credential access.

Can a malicious agent skill look completely normal in its documentation? Yes, and this is one of the more dangerous patterns researchers have found in the wild. A skill can describe itself as a Markdown formatter or GitHub helper while a helper script quietly searches for .env files or opens a connection the documentation never mentions.

Do curated, official skill repositories solve this? They reduce the risk but don't remove it. Official repositories are smaller and reviewed more closely. Most of the exposure comes from the far larger third-party marketplaces developers pull from directly, which grow faster than any team can manually review.

Related reading: "Shadow Features: The Malicious Capability Your Skill Scanner Never Sees," "Anatomy of a Real Attack: Dissecting a Data-Exfiltration Agent Skill"