--- title: "Agent Skill Catalogs Are a Supply Chain. Who Signs Yours?" slug: "agent-skill-catalogs-are-a-supply-chain" author: "Mikel Amigot" date: "2026-08-24 15:30:44" category: "Premium" topics: "agent skills, skill catalog governance, AI supply chain security, agent governance, skill cards, prompt injection, self-hosted AI agents, SKILL.md" summary: "Enterprise teams have stopped asking how to deploy an agent and started asking who is allowed to publish a skill. NVIDIA's verified skill pipeline treats agent capabilities as signed software artifacts — which makes the catalog a supply chain, and raises the question of who holds the signing key." banner: "" thumbnail: "" linkedin: | Enterprise AI teams have quietly changed the question they ask. It used to be "how do we deploy an agent?" Now it's "who is allowed to publish a skill, and who reviews it?" NVIDIA's verified agent skills pipeline is the clearest signal yet. Skills go through review, security scanning, quality evaluation, a documented skill card, and cryptographic signing before they reach the catalog. Their scanner checks for the things you'd expect — vulnerable dependencies, credential access, data exfiltration paths — and for things that only exist in agent land: hidden instructions, prompt injection, trigger abuse, excessive agency, tool poisoning. That is a software supply chain. Agents have arrived at the same place package managers did fifteen years ago. Here's the part most teams haven't worked through yet: a supply chain is governed by whoever holds the signing key and controls the registry. If your agent platform is managed SaaS, the vendor curates the catalog. You inherit their approval decisions, their review cadence, and their idea of acceptable risk. You get a very good allowlist that was not written for your risk profile — and no ability to run your own gate on top of it. On ibl.ai you own all the code and the data. The catalog is yours, the review gates are yours, and the registry runs inside your perimeter. Skills are portable SKILL.md folders under the open Agent Skills spec, so nothing you write is trapped in one vendor's format. Governance you don't control isn't governance. It's someone else's policy, applied to your data. #iblai #AgenticAI #EnterpriseAI #AIGovernance #SupplyChainSecurity #AIAgents --- ## The Short Answer **An agent skill catalog is a software supply chain: every skill is executable instruction text your agents load at runtime, so it needs the same signing, review gates, and version control as any dependency. The governance question is who curates it. On ibl.ai you own all the code and the data, so the catalog, the review gates, and the registry are yours — not a vendor's allowlist you inherit.** The shift is real and it is recent. Enterprise teams have stopped treating an agent as the unit of deployment and started treating the *skill* as the unit — which means the catalog, not the agent, is now the thing that needs governing. ## What is an agent skill catalog? A skill is a folder containing a `SKILL.md` file: metadata plus instructions telling an agent how to perform a specific task. It can bundle scripts, reference material, and templates alongside those instructions. The format comes from the [Agent Skills open specification](https://agentskills.io), originally developed by Anthropic and released as an open standard. It has since been adopted across a wide range of agent products. Agents load skills through **progressive disclosure**, in three stages. At startup an agent reads only each skill's name and description. When a task matches, it loads the full `SKILL.md`. Only then does it execute bundled code. That design is why catalogs get large. Full instructions load only when a task calls for them, so an organization can keep hundreds of skills available at a small context cost — and hundreds of anything is a governance problem. A catalog is the registry where those skills are discovered, installed, versioned, and audited. NVIDIA names several in its own documentation: GitHub, Skills.sh, ClawHub, and Hugging Face. ## Why are enterprises curating skill catalogs instead of deploying single agents? Because a skill is reusable and an agent is not. Write a contract-review skill once and every skills-compatible agent in the organization can use it — which is exactly the property that turns a pile of skills into shared infrastructure. NVIDIA's own framing is that teams should "manage agent capabilities with the same rigor applied to software libraries." That sentence is the whole maturity curve in one line. The comparison holds uncomfortably well. Software libraries got dependency scanning, signing, version pinning, and license review only after a decade of painful supply-chain incidents. The two that changed practice are worth naming. The SolarWinds Orion compromise, discovered in December 2020, reached more than 18,000 customers through signed official updates. Log4Shell (CVE-2021-44228), disclosed in December 2021, exposed how little most organizations knew about their own transitive dependencies. Signing, SBOMs, and provenance requirements are the direct institutional response to those two events. Skills are arriving at the same destination faster, because the industry already learned the lesson once. There is one difference that makes skills harder. A library is code an engineer reviews. A skill is *instruction text a model obeys* — so the attack surface includes everything a prompt can do, not just everything a compiler will run. ## What does NVIDIA's verified skill pipeline actually check? On May 19, 2026, NVIDIA published [NVIDIA-Verified Agent Skills Provide Capability Governance for AI Agents](https://developer.nvidia.com/blog/nvidia-verified-agent-skills-provide-capability-governance-for-ai-agents/) on its developer blog, describing a seven-stage flow: review, scan, evaluate, skill card, sign, catalog, sync. The scanner, SkillSpector, checks two distinct classes of risk — and the second class is the interesting one:
Risk class What it scans for Familiar from
Conventional software Vulnerable dependencies, suspicious scripts, dangerous code patterns, credential access, data exfiltration paths Any modern SCA tool
Agent-specific Hidden instructions, prompt injection, trigger abuse, excessive agency, tool poisoning Nothing — these are new
Verified skills are then cryptographically signed using detached `.oms.sig` files, verifiable with OpenSSF Model Signing tools. The signature is what makes the catalog auditable rather than merely curated. Each skill also ships a **skill card**: a machine-readable document recording what the skill does, who built it, how it is licensed, what it depends on, and what limitations, risks, and mitigations apply. NVIDIA publishes the schema in its [Trustworthy-AI repository](https://github.com/NVIDIA/Trustworthy-AI). NVIDIA's [Agent Skills glossary](https://www.nvidia.com/en-us/glossary/agent-skills/) adds a quality bar to the security one: evaluations covering trigger accuracy, task completion rate, and token efficiency before a skill is published. Three metrics, all measurable, none of them "does it feel good." ## Who decides which skills your agents are allowed to run? Here is the question the industry conversation keeps skipping, and it is the one that actually matters. A supply chain is governed by whoever holds the signing key and controls the registry. Everything else — the scanner, the skill card, the review gate — is downstream of that single fact. NVIDIA's verified catalog is genuinely good work, and for NVIDIA-accelerated capabilities it is the right default. But it is *NVIDIA's* allowlist, reflecting NVIDIA's risk assessment. It is not a statement about whether a skill is appropriate for a hospital, a law firm, or a federal agency. If your agent platform is managed SaaS, this is where you stop. The vendor curates the catalog, sets the review cadence, and decides what "acceptable risk" means. You inherit a very good allowlist that was not written for your risk profile — and you cannot run your own gate on top of it, because you do not control the runtime that loads the skills. That is the difference between using a catalog and governing one. A regulated buyer needs both: the vendor's signature *and* their own. On [ibl.ai](/product/agentic-os) you own all the code and the data. The registry runs inside your perimeter, your security team holds the signing key, and your review gate is the one that decides what reaches production. You can consume NVIDIA's verified skills and still require your own approval before anything executes against your records. This is the same argument we made about [sandboxed agent runtimes](/blog/nvidia-nemoclaw-sandboxed-ai-agents-ownable-infrastructure) — a control you cannot configure is a control someone else owns. ## How do you version and review agent skills like software? NVIDIA's glossary describes the target state directly: a centralized skill catalog with versioning, search, and access controls, plus governance policies specifying which skills are approved per environment. Read that last clause again, because it is the operationally hard part. *Per environment* means a skill cleared for a sandbox is not automatically cleared for production, and a skill cleared for one department is not cleared for another. That is standard practice in software release management and almost nonexistent in agent deployments today. Most organizations running agents have no environment-scoped capability policy at all. The mechanics are familiar once you accept the framing. Pin versions rather than tracking a moving registry. Require a signature check at load time. Keep an audit trail of which skill version answered which request. The last one is what auditors actually ask for, and it is only possible if the execution logs live on infrastructure you control. A vendor's summary export is not an audit trail. ## What happens to your skill catalog if you switch AI vendors? If skills are written to the open `SKILL.md` spec, the answer is: nothing. That is the point of a standard format, and it is why the specification being open matters more than which vendor promotes it. The portability is real and already demonstrated — the Agent Skills client showcase lists dozens of independent agent products supporting the same format, including [OpenClaw](/service/openclaw), the open-source runtime we support. Model portability is the same argument one layer down. Skills describe *procedure*; they do not hardcode a provider. A catalog written to the open spec survives a model swap, which is why running [model-agnostic](/product/agentic-os) matters as much for your skill library as it does for inference cost. The lock-in risk was never the format. It is the registry, the signing authority, and the runtime — all three of which are infrastructure decisions, not file-format decisions. Skills also compose with the other half of what makes an agent useful. We wrote about that pairing in [Memory and Skills](/blog/memory-and-skills-what-turns-an-agent-loop-into-a-real-ai-agent): memory gives an agent a past, skills give it reach, and neither is much use alone. ## What this means for a team building agents now The maturity curve is not speculative anymore. Signing, scanning, skill cards, quality evaluation, environment-scoped approval — those are the practices, and a major vendor has now shipped a reference implementation of all of them. The open question for any organization adopting them is narrower than it looks. Not *should we govern our skill catalog* — that is settled — but *do we hold the keys to the thing we are governing*. 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. When we say the catalog is yours, that includes the source code that runs it. The earlier pattern still holds, and it holds harder now: [agent plus skill equals capability](/blog/agent-skills-structured-knowledge-turning-ai-into-real-engineer). What changed is that capability is now a supply chain, and supply chains are governed by whoever signs them. ## 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.