Scan the Skill Before You Run It: Agent Skills Get Their First Security Checkpoint

A skill is code, and code needs a checkpoint

NVIDIA open-sourced a tool called SkillSpector this week. Its job is narrow and overdue: scan AI agent skills for security problems before an agent loads them. The project ships with detection for 64 vulnerability patterns, which is a number worth pausing on, because it implies somebody sat down and enumerated the ways a skill can go wrong.

Alongside it, Cloudflare published a security-audit skill that runs multi-phase audits against a codebase and emits machine-readable findings, and GitHub detailed a context-aware secret-detection classifier that raised the weighted acceptance of real findings by 11.5 percent while cutting median scan time by 86 percent. Three different teams, three different angles, same conclusion: the layer where agents get their instructions has become infrastructure, and infrastructure gets audited.

What a skill actually is

The word "skill" makes the whole thing sound softer than it is. A skill is not a setting. It is a bundle of instructions and, very often, scripts, templates, and tool definitions that an agent will read and follow with the permissions the agent has been granted.

That last clause is the security model in one sentence. A skill does not need an exploit, because it is not breaking in. It is being invited in, handed the keys, and asked to help. If its instructions are malicious or merely sloppy, the agent will act on them as if they were your own intent, because as far as it can tell, they are.

This is the same problem package managers faced decades ago, and it was solved the same way: by assuming the supply chain is hostile and building checkpoints into it. The agent ecosystem is early in that process, which is why a project like SkillSpector matters more than its star count suggests.

Why 64 patterns is the interesting number

A list of 64 vulnerability patterns is a taxonomy, and taxonomies are how a field matures. Before you have one, every incident is a surprise. After you have one, incidents become instances of known classes, which means they can be tested for, tracked, and eventually designed out.

Some of those classes are familiar from ordinary software: unsafe shell commands, unvalidated inputs, credentials written into files that should never hold them. Others are specific to this new layer. Instructions that widen the agent's scope without saying so. Prompts that pull in untrusted content and treat it as a command. Tool descriptions that misrepresent what a tool does, so the agent calls it for the wrong reason. Skills that chain other skills into a path nobody intended.

That last category is where the difficulty lives. A skill is dangerous precisely in proportion to how much it can reach, and modern agents can reach a lot: the filesystem, the network, other agents, the tools another skill registered. The blast radius of a bad skill is not the skill. It is everything the agent can touch, which is a moving target that depends on which other skills got loaded first.

The poisoned-context problem

The uncomfortable part of agent security is that the boundary between data and instruction is not enforced by anything. A model reads text. It does not inherently know which sentences are facts to consider and which are orders to obey.

So a skill that fetches a web page, or reads an issue tracker, or summarizes an email, is exposing the agent to text that may contain instructions. If the model follows them, there is no exploit in any traditional sense. There is just a system that did what it was told by something it should not have trusted.

This is why scanning has to happen at load time rather than at incident time. Once a skill is running inside an agent with broad permissions, the interesting question has already been answered badly. The checkpoint has to come first, and it has to be automatic, because human review of every skill in a registry does not scale and never will.

Auditing is becoming a product

The Cloudflare release points at a second trend. Its audit skill produces machine-readable findings rather than a list someone has to read. That phrasing is doing real work. Findings a human must read are findings a human will skim. Findings a pipeline can consume can be turned into tickets, blocked merges, or refused deployments without anyone needing to remember to look.

GitHub's secret-detection work fits the same pattern. Secret leakage scales with how much code is produced, and code production has gone up sharply. The response was not "hire more reviewers." It was a context-aware classifier that cuts noise, so that the alerts people do see are more likely to be real. Precision, in security tooling, is what determines whether anyone still reads the alerts after month three.

Both of these are the same move made at different layers. Instead of asking humans to be more vigilant, make the automated check good enough that human attention is only spent where it can matter. That is the only strategy that survives contact with volume.

The governance question underneath

There is a policy layer here that is moving faster than most teams realize. Version control systems are starting to carry provenance metadata. Package registries are adding attestation. Standards bodies are working on how to label synthetic content and how to identify an agent. The direction of travel is toward a world where the origin and integrity of an artifact must be provable, not assumed.

Skills sit awkwardly in that world, because the same skill can be useful and dangerous depending on context. A skill that can modify files is essential for a coding agent and catastrophic for an agent that also reads untrusted email. The trust decision is not a property of the skill alone. It is a property of the skill plus the environment plus the other skills it can reach.

Which suggests the scanners will eventually need to do more than pattern-match. The genuinely hard version of this tool checks whether a proposed combination of skills grants a capability nobody asked for, and warns before it ships rather than after.

What teams should do now, without overreacting

Panic is not the right response, and neither is treating this as somebody else's problem.

The practical moves are unglamorous. Treat third-party skills as untrusted dependencies, because that is exactly what they are. Pin versions and review diffs when they change. Run agents in environments where the blast radius is bounded, so a bad skill cannot reach the network or the production database just because the agent was convenient. Log what skills loaded and what they did, because the first hard question after any incident is what was allowed to run.

The industry has walked this path before. Package ecosystems were insecure, then they were made tedious to attack, and the tedium is the point. Agent skills are heading for the same equilibrium, and the projects shipping this week are the first serious attempt to build the checkpoint. Getting there before the incident is cheaper than getting there after, and the only thing required to get there early is a willingness to be boring about it.