The Short Answer
NVIDIA's SkillSpector scanner operationalizes a January 2026 study by Liu et al., which collected 42,447 agent skills and analyzed 31,132: 26.1% contain at least one vulnerability and 5.2% show high-severity patterns strongly suggesting malicious intent. Agent skills are executable third-party code with credentials and tool access, installed with less review than a npm package. With ibl.ai you own all the code and the data, so the agent supply chain is inside your perimeter and auditable.
The scanner has been public since March 2026. The finding underneath it is the part that still has not landed: roughly one agent skill in twenty on public marketplaces shows patterns strongly suggesting malicious intent, and almost nobody is checking.
What does the research behind NVIDIA's SkillSpector actually find?
Three numbers — and the attribution matters, because they are not NVIDIA's. They come from "Agent Skills in the Wild" by Yi Liu, Weizhe Wang, Ruitao Feng and colleagues, submitted 15 January 2026, which collected 42,447 skills and analyzed 31,132 of them.
NVIDIA's scanner cites the study; it did not produce it.
| Finding | Share |
|---|---|
| Contain at least one vulnerability | 26.1% |
| Show likely malicious intent | 5.2% |
| Relative risk when a skill ships executable scripts | 2.12x |
SkillSpector, open-sourced in March 2026 and updated weekly since, covers 60-plus vulnerability patterns across more than a dozen categories — prompt injection, data exfiltration, privilege escalation, supply-chain attacks, excessive agency, memory poisoning, tool misuse, rogue agent behaviour, trigger abuse, dangerous code via AST analysis, taint tracking, YARA signatures, and MCP-specific risks.
Point it at a directory, a zip, a single SKILL.md or a Git URL and it returns findings, a risk score and recommendations.
Two of its checks describe the problem precisely. One flags wildcard permissions — a skill requesting *, all, full or any, which grants everything and reads as boilerplate.
The other flags skills that declare no permissions field at all while shipping code with plainly detectable capabilities.
Why are agent skills a bigger exposure than a normal package dependency?
Because a skill does not just run in your environment — it acts on your behalf inside it.
A compromised npm package runs with the privileges of the build or the app. A compromised agent skill runs with the agent's tool access: the systems it can query, the credentials it holds, the actions it is allowed to take.
It also sits downstream of a model that can be steered by text, which means prompt injection becomes a delivery mechanism for whatever the skill can already do.
The installation culture makes it worse. Skills spread the way browser extensions spread in 2010 — an engineer finds one useful, installs it, tells a colleague. There is usually no review gate, no inventory and no owner.
That is the "shadow agent" problem: not a rogue AI, but ordinary employees adding capable third-party code to systems that security has never seen.
Is a pre-deployment scanner enough to make agent skills safe?
No, and treating it as sufficient is the mistake worth naming.
A scanner answers one question well — should I install this? It reads a skill before deployment and tells you whether its declared permissions match its actual behaviour. That is genuinely valuable and, at 5.2% likely-malicious, overdue.
What a scanner cannot do is constrain a skill once it is running. It cannot stop a skill that passed review from being updated later, from being steered by injected text at runtime, or from using a permission it legitimately holds in a way nobody intended.
Static analysis before deployment and containment during execution are different controls, and the second is the one that holds when the first is wrong.
Containment is architectural.
It means skills execute in a sandbox rather than in the agent's own context, with outbound traffic restricted to allowlisted hosts.
It means permissions are scoped per skill and enforced server-side, where neither the model nor a differently-configured client can widen them.
Every tool call and data access is written to an audit trail, and network egress is governed by policy rather than by trusting the skill not to phone home.
What should an enterprise do about agent skills this quarter?
Four things, in order, and none requires waiting for a standard to settle.
- Inventory what is already installed. Most organizations cannot currently answer which agent skills are running against their systems, which is the same position they were in with SaaS in 2015. You cannot govern an inventory you do not have.
- Scan before install, and re-scan on update. A skill that passed review in June is not the skill you are running in September if it has auto-updated since.
- Scope permissions to the task. A wildcard permission is a finding, not a default. If a skill needs read access to one system, it should not hold write access to four.
- Enforce at the infrastructure layer. A permission the agent can widen is not a permission. This is the same lesson banks are learning about AI governance: controls implemented in prompts fail exactly when they are needed.
How does ibl.ai handle the agent skill supply chain?
By making the supply chain something you own rather than something you subscribe to.
With ibl.ai you own all the code and the data.
The platform is deployed on your own infrastructure with full source code access, which means the agent runtime, the skills it can load and the policies that constrain them are all inside your perimeter and reviewable by your own security team — not a vendor's opaque marketplace.
Agent-executed code runs in sandboxes with outbound traffic restricted to allowlisted hosts, permissions are RBAC-scoped and enforced server-side, and tool calls are audited.
Deployment reaches as far as a fully air-gapped network, where the marketplace supply chain is simply not reachable.
The platform is also model-agnostic and usage-based with no per-seat pricing, so security posture and commercial terms are not in tension.
ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned partner, which matters when the question is who is accountable for the code your agents run.
Related reading: why sandboxed AI agents are the right default.
Sources: the 42,447-collected / 31,132-analyzed corpus and the 26.1%, 5.2% and 2.12x figures are from "Agent Skills in the Wild: An Empirical Study of Security Vulnerabilities at Scale" (Liu, Wang, Feng et al., January 2026) — not from NVIDIA. Scanner behaviour and coverage from the SkillSpector repository and Help Net Security.