Right now, developers are downloading third-party skills straight off GitHub for their agents. Ten minutes saved, a new capability, done.

The problem is what almost nobody processes: an AI skill is not a prompt. It’s executable code that runs with your system’s privileges. The skill you grabbed to save time can read your environment variables, lift your API keys, and send them to an external server while it also does the thing it said it would do.

That’s the thesis, and it comes before the tool: installing a skill without reviewing it is installing a code dependency without reviewing it, with everything that implies. For companies building on agents, and even more when we build for clients, that turned skill vetting into part of delivery, not a technical footnote. It’s exactly the kind of risk Socio Tecnológico covers.

The numbers that force a stop

Charly Wargnier summarized on LinkedIn the figure that makes this urgent: research found 26.1% of public skills carry vulnerabilities and over 5% are outright malicious.

Sit with those numbers. This isn’t an edge case or an alarmist headline. One in four skills circulating in public repositories carries a vulnerability, and more than one in twenty was built to do harm. If your team installs third-party skills with the same ease it copies a Stack Overflow snippet, you’re already exposed. The difference is that the Stack Overflow snippet doesn’t run on its own with access to your secrets. The skill does.

The reason this surprises people is a category mistake. The word skill sounds like configuration, like an instruction text you hand the model. But a skill packages code that executes. It has the same level of access as any script you run on your machine or server: your environment variables, your file system, your network. Treating it like a prompt is the mistake that makes it dangerous.

What SkillSpector does, without overselling it

NVIDIA released SkillSpector under the Apache 2.0 license, and it answers one question: is this skill safe to install?

The flow is direct. You point it at a GitHub link, a local folder, or a single SKILL.md file. The first pass is a fast static scan that flags credential harvesting, prompt injections, and checks live CVE data. The second pass, optional, uses a model to evaluate the semantic intent of the code and clear out false positives. At the end it hands you a 0 to 100 risk score and a clear verdict: safe, caution, or do not install. It scans skills for Claude Code, Codex CLI, and Gemini.

It’s a tool worth running before you trust the next skill you find. But here’s where I have to be honest, because the part that gets skipped is the part that matters.

An install-time scan isn’t runtime trust

The sharpest counterargument to this class of tool came up in the same threads. A scanner at install time reviews a state. Agents don’t operate in a fixed state: they pull and chain skills dynamically at runtime. A skill can pass the scan and then behave differently depending on the context it receives, or invoke another skill you never reviewed.

That doesn’t void SkillSpector. It places it. It’s a defense layer at install time, not a guarantee of behavior. Trust has to be continuous, not a one-time gate. Anyone selling a scanner as a complete solution is repeating the mistake the scanner tries to correct: treating a runtime problem as if it were a static-review problem.

Some take the argument further and say that without open, end-to-end reproducible code, any scanner is security theater. I don’t share the extreme, an imperfect layer beats none, but the core is right: install-time review reduces risk, it doesn’t remove it. The operational question isn’t “do I run the scanner or not?” It’s “who owns the decision of which skills reach production, and who watches them once they’re running?”

What this means if you build for clients

Here’s the angle that changes the math for a services company. When you build agents for a client, you ask for access to their CRMs, their APIs, sometimes their full stack. If a skill you took from a public repository lifts those keys, the damage isn’t a technical incident you patch. It’s the client’s trust, and it’s your reputation.

This connects to things we’ve covered. In the post on the traps agents read the risk came from content the agent consumes without you seeing it. In the post on the LiteLLM attack it came from a broken dependency chain. Skills are the same family of risk: attack surface that walks in through the “this saves me time” door. The AI supply chain isn’t only models and libraries. It now includes the skills your agent loads.

Socio Tecnológico treats that surface as part of the job, not an extra. We own the role that defines which skills can enter a project, reviews them before use, and designs the control of what each agent can touch once it’s in production. For a client who trusts us with their operation, verifying a third-party skill isn’t optional, it’s part of delivery due diligence. Running a scanner like SkillSpector before touching anything third-party is the baseline, not the finish line.

Before the week closes, ask your team one question. The last skill or agent tool someone installed from a public repository, who reviewed it, and does that person know what it had access to while it ran? If the answer is that nobody reviewed it because it came recommended, you already know where your next breach is. A sophisticated attacker didn’t open it. Someone on your team installed it to save ten minutes.

Put control over what your agents install and run