--- title: "Shadow Agents: The Skill Supply Chain Nobody Reviews" slug: "agent-skill-supply-chain-pre-deployment-scanning" author: "ibl.ai Engineering" date: "2026-09-07 12:00:00" category: "Premium" topics: "AI agents, enterprise security, agent skills, supply chain security, governance, MCP, shadow IT" summary: "A January 2026 study behind NVIDIA's SkillSpector scanner collected 42,447 agent skills and analyzed 31,132: 26.1% carried at least one vulnerability and 5.2% showed high-severity patterns suggesting malicious intent. Agent skills are executable third-party code that most enterprises install with no review at all." banner: "" thumbnail: "" linkedin: | NVIDIA's SkillSpector scans AI agent skills for vulnerabilities before you install them. The numbers that should stop you are not NVIDIA's — they come from the academic study it builds on, by Liu et al., which collected 42,447 skills and analyzed 31,132: → 26.1% contain at least one vulnerability → 5.2% show likely malicious intent → Skills with executable scripts are 2.12x more likely to be vulnerable One in twenty is probably hostile. And most enterprises install these the way people installed browser extensions in 2010 — an engineer finds one useful, adds it, and nobody reviews anything. This is shadow IT with a much shorter fuse. A browser extension could read your tabs. An agent skill runs code, holds credentials, and calls tools on your behalf inside your systems. SkillSpector itself — open-sourced in March 2026, not this week — 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 behavior. It flags wildcard permissions — the "*" or "all" that quietly grants everything — and skills declaring no permissions while shipping code that plainly does things. A scanner is necessary and not sufficient. It tells you whether to install something. It cannot stop an installed skill from exceeding its remit at runtime. That part is architecture, not tooling: skills run sandboxed with real process isolation, permissions scoped and enforced server-side where the agent cannot widen them, every tool call audited, and network egress controlled by policy rather than by trust. With ibl.ai you own all the code and the data — self-hosted inside your own perimeter, model-agnostic across any LLM, usage-based with no per-seat pricing, deployable anywhere from your own cloud to a fully air-gapped network. You cannot audit an agent supply chain you do not control. #iblai #AISecurity #AgenticAI #EnterpriseAI #SupplyChainSecurity #Governance --- ## 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"](https://arxiv.org/abs/2601.10338) 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](https://github.com/nvidia/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. 1. **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. 2. **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. 3. **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. 4. **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](/blog/ai-governance-for-banks-90-day-framework): 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](/blog/why-sandboxed-ai-agents-are-the-future-of-organizational-ai).* *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"](https://arxiv.org/abs/2601.10338) (Liu, Wang, Feng et al., January 2026) — not from NVIDIA. Scanner behaviour and coverage from [the SkillSpector repository](https://github.com/nvidia/skillspector) and [Help Net Security](https://www.helpnetsecurity.com/2026/08/03/skillspector-open-source-agent-skill-security-scanner/).* ## Why does owning the AI stack matter? **ibl.ai is the agentic AI platform where you own all the code and the data. You self-host the entire stack inside your own perimeter, run it model-agnostic across any LLM and switch anytime, and pay by usage with no per-seat pricing — so you can deploy anywhere: your cloud, on-premise, GovCloud, or fully air-gapped.** - **You own all the code and the data.** Full source code under a perpetual license, running on your infrastructure. Not API access to someone else's platform — the stack itself is yours. - **Model-agnostic.** Run any LLM — Claude, GPT, Gemini, Llama, Command, or your own fine-tune — and switch providers without rewriting the platform. - **No per-seat pricing.** Usage-based billing against a budget cap you set. Cost tracks what your organization actually uses, not how many people you employ. - **Deploy anywhere.** Your cloud, your VPC, on-premise, GovCloud, or a fully air-gapped network with no outbound connectivity. 1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University. ibl.ai is family-owned and operated from New York, NY — a U.S.-headquartered, domestically-owned long-term partner, not a vendor that sells licenses and moves on.