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, 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 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.
NVIDIA's Agent Skills glossary 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 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 — 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, 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 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: 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. What changed is that capability is now a supply chain, and supply chains are governed by whoever signs them.