Agent skills have a supply chain problem. NVIDIA just shipped the first structural fix.
On 5 February 2008, Baxter International initiated the largest pharmaceutical recall in US history. 81 Americans were dead. Hundreds more had experienced anaphylaxis and cardiac events after routine intravenous heparin infusions. The FDA traced the contamination back to a manufacturing facility in Changzhou, China that its inspectors had never visited. The raw active pharmaceutical ingredient had been deliberately substituted with over-sulfated chondroitin sulfate (OSCS): a cheap synthetic lookalike that passed every standard pharmacopoeia assay but caused fatal immune responses under real physiological conditions.
The distribution chain had trusted catalog membership. Baxter was a reputable supplier. The Chinese facility held GMP certification. Nobody had looked inside the ingredient itself.
In early 2026, Snyk’s ToxicSkills research scanned 3,984 agent skills listed on ClawHub. 13.4% had critical security issues. 36% contained prompt injection vectors. 76 were confirmed credential-stealers or backdoor payloads. The catalog had grown 10x in weeks. The vetting hadn’t.
NVIDIA shipped its Verified Agent Skills framework on 22 May 2026: SkillSpector scanning, machine-readable skill cards, and cryptographic signing. The architecture maps almost exactly onto what pharmaceutical supply chains built after Changzhou. This post breaks down what each component does, where the gaps are, and the 5 controls your team should have in place right now regardless of whether your skills come from the NVIDIA catalog or anywhere else.
Agent skills aren’t npm packages. The threat model is completely different.
The agentic AI community borrowed the mental model from package management and hasn’t updated it since. An npm package runs in a JavaScript runtime with explicit permission boundaries. A malicious npm package causes damage; the blast radius is defined by the runtime scope.
An agent skill loaded into Claude Code, Cursor, or Codex runs with the full permissions of that agent. It can read your entire codebase, access environment variables, make outbound API calls, and execute shell commands. There’s no sandbox. When Snyk’s researchers confirmed 76 backdoor payloads in publicly listed skills, they weren’t describing theoretical attack paths. They were describing capabilities already active in developer environments, running with full agent permissions, doing things the developers who installed them didn’t know they were doing.
Agent skills are closer to pharmaceutical active pharmaceutical ingredients than to software libraries. They’re portable instruction sets. What they instruct depends entirely on what’s inside them. And unlike a library call, you often can’t see what they’re instructing until it’s done.
The pharmaceutical industry learned this the hard way and spent four decades building the analytical infrastructure, regulatory oversight, and supply chain documentation to catch contaminated or adulterated ingredients before they reached patients. The agent skills ecosystem is having the same reckoning, compressed into months instead of decades.
SkillSpector runs two stages. The second one is the one your pipeline is probably skipping.
Before any skill reaches NVIDIA’s verified catalog, it goes through SkillSpector. The tool is open-source and pip-installable, so you can run it against any skill directory, not just NVIDIA’s.
Stage 1 is conventional static analysis: vulnerable dependencies, suspicious scripts, dangerous code patterns, credential exposure paths, and potential data exfiltration routes. Across 16 categories, SkillSpector checks 64 vulnerability patterns. If you’ve worked with Snyk, Semgrep, or Trivy, you understand the output format. Most security teams can wire this into a pipeline in under an hour.
Stage 2 is where it becomes different from anything else in the current tooling landscape. SkillSpector uses LLM semantic evaluation to check for agent-native threats: hidden instructions, prompt injection, trigger abuse, excessive agency, tool poisoning, and purpose-access mismatches. The alignment with OWASP’s LLM application guidance and MITRE ATLAS threat intelligence means Stage 2 is grounded in a structured taxonomy of agent compromise, not just pattern matching against known malicious signatures.
Most teams run Stage 1 equivalent checks, if they run anything at all. Stage 2 is what the Changzhou factory inspection would have caught: the thing that looks clean by every standard test but fails under real conditions.
Why file-by-file review misses the actual threat
The OSCS contamination passed standard anticoagulant activity assays because OSCS has chemical properties similar enough to heparin to fool routine testing. Only NMR spectroscopy, which wasn’t part of the standard USP monograph at the time, could distinguish them. The FDA added NMR requirements to the heparin monograph after 81 people died. The testing method mattered as much as the decision to test.
The agent skill equivalent is the intent mismatch check. A skill can pass every file-by-file security scan and still be steering your agent toward unsafe behavior. It can request broader access than its stated purpose requires. It can describe one task while the bundled artifacts enable something different. Standard static analysis tools don’t catch this because the threat lives in the semantic layer: in what the skill means to do, not just what it literally contains.
Purpose-access mismatch is the primary attack vector in the current agent skill threat landscape. An attacker doesn’t need to smuggle malicious code past your scanner. They write plausible skill documentation, request access the agent will grant without scrutiny, and let the agent do the rest.
In practice, your security review of any agent skill needs to include a capability-access audit: what permissions does this skill actually need for what it claims to do? A code generation skill shouldn’t need network egress. A documentation assistant shouldn’t need filesystem write access. If the gap between declared purpose and requested access isn’t explainable by the skill’s stated function, that’s your signal. SkillSpector automates the detection. The judgment call on acceptable risk still needs a human.
The skill card is the package insert. Treat it like one.
Every FDA-approved drug ships with a package insert: a structured document listing active ingredients, contraindications, known adverse effects, interaction risks, and approved use cases. It exists because the manufacturer knows things about the drug that the prescriber doesn’t, and those things are material to safe use.
In 2004, Merck withdrew Vioxx from the market after 4 years of widespread use. Post-withdrawal analysis confirmed that the cardiovascular risk signal had been present in clinical trial data before withdrawal. An FDA scientist later estimated that tens of thousands of Americans may have died from Vioxx-linked heart events during those 4 years. The trust record (the package insert’s adverse events section) hadn’t adequately reflected what was known. The documentation gap was as dangerous as a supply chain gap.
NVIDIA’s skill card is the agent skill equivalent. It’s a machine-readable YAML/JSON document that travels with every verified skill:
- Ownership and provenance: who built it, which organisation maintains it, issue reporting contacts
- Licensing terms: what you can and can’t do with it in production
- External dependencies: which APIs, services, or libraries the skill calls out to
- Known limitations: edge cases where behavior is unpredictable, deployment scenarios where the skill shouldn’t be used
- Risk assessment: vulnerabilities identified during scanning and recommended mitigations
- Verification status: scan date, signing status, review type (automated vs. human)
Your compliance team already knows how to work with this format. They read it for third-party APIs, cloud service dependencies, and software component audits. The skill card extends that audit trail into the agent capability layer.
If a skill doesn’t ship with a card, treat that absence the same way you’d treat a pharmaceutical with no package insert. The missing documentation is itself a risk signal.
Signing vs. catalog membership: two different security properties
Between 2003 and 2013, Indian pharmaceutical manufacturer Ranbaxy systematically falsified stability data and quality test results. Batches that failed internal specifications were shipped while certificates of analysis were fabricated. The FDA had trusted the certificates. The certificates were lies. Ranbaxy pled guilty in 2013 and paid $500M in fines. Drugs from that production had been distributed globally for a decade.
Catalog membership has the same structural weakness as a GMP certificate: it tells you where a skill was published and that it met a standard at a point in time. It doesn’t tell you whether the artifact you downloaded matches what was reviewed, or whether it was modified between publication and your install.
NVIDIA’s signing layer uses OpenSSF Model Signing anchored to NVIDIA’s Agentic Capabilities root
certificate. Each verified skill ships with a detached skill.oms.sig file. Verify it
post-download: if the skill directory was modified after signing, verification fails. That’s the
check Baxter didn’t have and that FDA certificate-based oversight couldn’t provide.
Catalog membership tells you where a skill came from. Signature verification tells you whether what you received matches what was signed. Run both. For audit purposes, your security team will be asked to demonstrate both when something goes wrong.
The coverage gap your compliance team won’t ask about until it’s too late
The NVIDIA verified catalog covers NVIDIA’s own CUDA-X libraries, AI Blueprints, and platform tools. That’s a meaningful slice of the skills used in AI infrastructure work, and a small fraction of the total agent skill ecosystem any active engineering team actually runs.
Most teams pull skills from GitHub repositories, community sources, and their own internal development. They build custom skills for internal tooling, patch published skills to fit their stack, and run experimental skills from contributors who’ve never submitted anything to a formal verification pipeline. The NVIDIA catalog doesn’t cover any of that. Neither does any other catalog.
The pharmaceutical industry faced the same jurisdictional boundary problem. Compounding pharmacies operated outside FDA oversight for decades because they classified themselves as pharmacies rather than manufacturers. The 2012 NECC meningitis outbreak killed 64 people through contaminated methylprednisolone injections produced in conditions that met no manufacturing standard. The NECC was a compounding pharmacy operating at manufacturer scale, outside manufacturer oversight. The gap between regulatory coverage and clinical reality was fatal.
The gap between what any verification framework covers and what teams actually deploy is where supply chain attacks find their footing. NVIDIA’s answer to this is deliberate: SkillSpector is open-source specifically so teams can run it against skills from any source. The catalog is a starting point, not a perimeter. Extend the tooling to cover your full skill surface area, not just the subset with a verified badge.
The Verified Capability Stack: 5 controls for every agent skill your team runs
These 5 controls apply to any agent skill your team loads: NVIDIA catalog, GitHub, community repo, or internally built.
Control 1: Scan before install, not after incident
Wire SkillSpector into your CI pipeline before skills reach developer environments.
pip install skillspector
# Scan a local skill directory
skillspector scan ./skill-directory/
# Scan from GitHub directly
skillspector scan https://github.com/someone/their-skill
# SARIF output for pipeline integration (GitHub Advanced Security, Azure DevOps)
skillspector scan ./skill-directory/ --format sarif > results.sarif
The scan runs in under 2 minutes for most skills. SARIF output drops straight into GitHub Advanced Security and Azure DevOps Security dashboards. One pip install. No architectural changes. The barrier to entry is lower than any alternative.
Control 2: Audit intent against access scope
Read what the skill claims to do. Then read what it actually requests access to. A CUDA kernel optimisation assistant shouldn’t need network egress. A documentation skill shouldn’t need filesystem write access. If the gap between declared purpose and requested access isn’t fully explainable by the skill’s stated function, hold it until it is.
This is a manual check right now for skills without a SkillSpector Stage 2 report. Schedule 30 minutes with your security team to build a lightweight scope-checking template. Apply it to every external skill before it reaches any environment with production data access.
Control 3: Require a skill card for anything going to production
NVIDIA has published the skill card template and generator under open licence. Build your own skill cards for internally developed skills. Require them from any external skill you bring into production. An undocumented skill in a production agent is a liability waiting for a trigger event, not a feature.
The skill card also gives your compliance team something to point to. When your CISO asks what your agents can do, you have standardised, structured answers. When a skill is found to contain a vulnerability after deployment, the card tells you which agents are running it so you can respond systematically instead of manually.
Control 4: Verify the signature at deploy time
For NVIDIA-verified skills, verify the skill.oms.sig file against the skill directory
before deploying. If you’re building internal skills, sign them using the same OpenSSF tooling.
Adding signing to a release pipeline takes under an hour. The absence of signature verification
means you’re trusting the transfer mechanism, not the artifact. Transfer mechanisms get compromised.
Control 5: Gate at the pipeline, not at developer judgment
Configure your CI/CD pipeline to fail if a skill hasn’t been scanned, doesn’t carry a skill card, and can’t be signature-verified. Move the control point from individual decision to automated gate.
Developer judgment on agent skill safety is inconsistent under deadline pressure. One engineer reviews carefully; the next doesn’t. Automated gates aren’t inconsistent. They also don’t get overridden at 11pm on a Friday when someone needs to ship a demo. This single change gives you more durable coverage than any training programme or policy document.
The only question that matters
The pharmaceutical industry spent 40 years building verification infrastructure because the cases where trust failed were catastrophic and the market couldn’t self-correct. It didn’t start with a complete solution. It started with NMR spectroscopy in the monograph, package inserts in regulatory submissions, and chain-of-custody documentation at facility level. The structure came first. The coverage expanded over time.
The agent skills ecosystem is at the beginning of the same sequence. The ToxicSkills data gives you the baseline: 13.4% critical compromise rate, 76 confirmed backdoors, 500 new skills published per day. Your developers are installing skills from community repos right now with the same level of scrutiny they apply to npm packages, which is to say, not much.
NVIDIA’s framework gets the structure right. SkillSpector covers what the USP monograph addition covered: a test method that can actually catch the threat. Skill cards cover what package inserts cover: documented trust metadata in a standardised format. Signing covers what chain-of-custody documentation covers: verifiable proof that the artifact you received matches what was reviewed.
What percentage of the agent skills in your current development environment have been through SkillSpector, carry a skill card, and have a verified cryptographic signature? All 3. Not one or two.
If you can’t answer that, start with a SkillSpector scan on whatever your agents are running today. That’s your baseline. Build the Verified Capability Stack from there.
Bola Ogunlana is a Senior DevSecOps Engineer with 25+ years in cloud infrastructure, UK Government delivery, and financial services. He writes at blog.ogunlana.net.