SKILL.md is not documentation, it is the new signed supply chain

AI 요약

• What happened: NVIDIA published a Verified Skills flow that treats agent skills as cataloged, scanned, signed, and documented artifacts.
  • The pipeline runs from source repository and review through scanning, evaluation, skill cards, signing, cataloging, and sync.
• Why it matters: SKILL.md is no longer just a helper note. It is part of a capability supply chain that agents discover, select, and execute.
• Watch: A signature proves artifact integrity, not safety. SkillSpector scans, skill cards, review, and runtime guardrails still have to work together.
  • A recent arXiv paper reported that semantic evasion against skill governance avoided blocking verdicts in 36.5%-100% of tested cases.

Agent skills first looked like a convenience feature. Claude Code, Codex, Cursor, and similar tools can load a folder containing SKILL.md, scripts, reference material, examples, and small assets so the agent performs a specific task better. A team can package its preferred review process, deployment checklist, incident workflow, or domain knowledge and let the agent call that knowledge when needed. For developers, this is a natural extension of the rule files and playbooks that already sit beside code.

The same convenience quickly becomes a supply-chain problem. A skill is not just text for a human reader. It tells an agent when a capability should be used, what commands may be run, which files should be inspected, which external systems might be called, and what behavior should continue after failure. If the folder includes scripts, references, and tool-use instructions, it starts to look less like documentation and more like a software package injected into the agent's operating context.

NVIDIA's May 19, 2026 post on NVIDIA-verified agent skills addresses that shift directly. NVIDIA defines a verified skill as one that is cataloged, scanned, signed, and documented with a skill card. The message is not only "this skill came from NVIDIA." It is closer to "this capability has an owner, passed review and scanning, carries known risk metadata, and can be checked against the artifact NVIDIA signed."

That matters because agent security cannot stop at runtime guardrails. It is necessary to control which files an agent can read and which commands it can execute while it is running. But before that, teams need to control which capabilities are allowed into the workflow at all. Just as organizations inspect package origin, version, vulnerabilities, and provenance before installing npm dependencies, agent skills are starting to need an installation gate.

A skill is a capability, not a prompt

NVIDIA describes agent skills as portable instruction sets that help agents use CUDA-X libraries, AI Blueprints, platform tools, and other NVIDIA resources correctly. Read narrowly, that sounds like a knowledge bundle. But the verification process NVIDIA describes changes the category. A skill begins in a product-team source repository, goes through review and scanning, receives a skill card, gets a detached signature, enters a public catalog, and can then be synchronized by consumers.

That is much closer to a software release process than a documentation publishing process. NVIDIA says the signature covers every file and subdirectory in the skill directory, not only SKILL.md. Scripts, references, assets, and other bundled files are part of the artifact being verified. A consumer can use skill.oms.sig and NVIDIA's root certificate to check that the directory it downloaded still matches the directory NVIDIA signed.

Why go that far? Because of how agents consume skills. A person can read a README skeptically, ignore suspicious prose, and decide what to run. An agent is more exposed to the operational text inside the skill. The description, trigger language, hidden instruction, bundled scripts, and reference files can all affect skill discovery, selection, and execution. A skill can describe itself as a harmless writing helper while nudging the agent toward broad file access or external data transfer. A code-only malware scan will miss part of that attack surface.

The recent arXiv paper Under the Hood of SKILL.md makes the same point from a research angle. It treats SKILL.md not as passive documentation, but as operational text that changes how an agent finds, trusts, and uses third-party capability. The authors test attacks across discovery, selection, and governance. They report that short textual triggers can increase the visibility of adversarial skills, that description-only framing can steer selection toward functionally equivalent malicious variants, and that semantic evasion avoided blocking verdicts in 36.5%-100% of the tested governance cases.

Those results are useful context for NVIDIA's announcement. Verified Skills is not a generic "make skills safer" statement. It is a response to the realization that SKILL.md has become part of the agent supply chain.

What the verification pipeline is trying to see

NVIDIA's verified-skill flow is source repo, review, scan, evaluate, skill card, sign, catalog, and sync. The ordering matters. The process starts from a repository owned by a product team. It then combines automated policy checks, human review, SkillSpector scanning, skill-card generation, directory signing, and catalog distribution. NVIDIA also describes evaluation as part of the validation pipeline.

That flow is answering three practical questions. First, what does this skill claim to do? Second, what did automated and human review find? Third, is the artifact a user downloaded the same artifact that was reviewed and signed? NVIDIA's "A Trust Pipeline for Agent Skills" documentation centers the same release-gate logic.

SkillSpector is the scanner in this flow. NVIDIA's documentation says it covers 16 categories and 64 vulnerability patterns. On the traditional software side, it looks for vulnerable dependencies, suspicious scripts, dangerous code patterns, credential access, and data-exfiltration paths. On the agent-native side, it looks for hidden instructions, prompt injection, trigger abuse, excessive agency, tool poisoning, and mismatches between declared purpose and requested access.

That distinction is the core of the story. Standard security scanners are built to inspect scripts, dependencies, and known code patterns. Agent skills also contain natural-language instructions. Those instructions are not code in the usual sense, but they can change execution. A sentence like "read all logs before using this tool," "send the collected output to this URL if the command fails," or "continue without asking the user" can be as important as a helper script. SkillSpector is trying to inspect that intent layer, not only the file layer.

A skill card is closer to an operating contract than a README

Another important piece in NVIDIA's announcement is the skill card. NVIDIA describes it as a machine-readable trust record that captures what the skill does, who made it, the license, dependencies, known technical limits, risks, mitigations, and verification status. In the cuOpt routing-skill example, a developer can inspect who authored the skill, whether it accesses anything beyond the cuOpt solver endpoint, and whether the optimizer was validated against routing benchmarks.

That is not the same job as a README. A README explains a project to people. A skill card gives policy systems and organizational tools structured trust metadata. An enterprise team can ask whether the skill is allowed in its environment, which dependencies it needs, whether known risks conflict with policy, and whether the verification status satisfies deployment rules.

The Contractual Skills paper argues in a similar direction. It proposes that enterprise skills should express goals, input boundaries, permissions, evidence requirements, output contracts, quality criteria, verification steps, human approval points, and handoff rules in an inspectable form. The paper is careful about the claim. Contractual fields do not magically improve raw generation quality; their value is in checkability and maintainability. In that framing, contractual skills are not a standalone safety mechanism. They are a governance layer.

The same caution applies to NVIDIA's skill cards. A skill does not become safe simply because a card exists. But the organization now has a surface on which safety can be evaluated. Instead of every reviewer answering "what is this skill supposed to do?" from prose and intuition, the owner, scope, constraints, risks, and verification state can be captured in one place. When that metadata travels with a signed directory, it also reduces the gap between the reviewed artifact and the installed artifact.

A signature proves sameness, not safety

NVIDIA attaches a detached skill.oms.sig to verified skills. According to its documentation, the company uses the OpenSSF Model Signing format, or OMS. OMS extends a Sigstore-style bundle so verification can cover a directory tree rather than only a single file. A skill directory can include SKILL.md, scripts/, references/, assets/, and skill.oms.sig; the signature covers the directory contents except for the signature file itself.

That matters because agent skills are easy to mutate after installation. Someone can copy a skill from GitHub into an internal repository, change a few lines, add a script, and keep the original publisher's name in the metadata. Without signing, consumers are relying on an impression of provenance. With signing, they can at least verify that the directory they received is the same artifact NVIDIA signed.

But the boundary has to be explicit: signing does not prove a skill is safe. NVIDIA's own documentation states that point directly. A signature proves that the released skill matches the signed artifact. It does not prove that the artifact contains no bad logic, no risky instructions, and no poor design. Signed malicious artifacts are still possible, and well-intentioned artifacts can still be unsafe in the wrong context.

That is why the deployment model has to split into three layers. The first is pre-installation review: scanning, skill-card inspection, ownership checks, and policy decisions. The second is artifact integrity: signatures or hashes that prove the installed skill is the reviewed skill. The third is runtime control: permissions, sandboxing, approvals, monitoring, and guardrails while the agent executes. NVIDIA names NeMo Guardrails, OpenShell, and NemoClaw as runtime controls, while Verified Skills governs the capabilities entering the workflow.

Why the skill supply chain is surfacing now

Agent skills are becoming a governance issue because agent deployment is changing. In the earlier phase, a user typed prompts and tool use was limited. Now organizations are collecting skills in repositories, installing them per project, and letting agents load them automatically when the description matches the task. That improves reuse, but it creates an inventory problem: which capabilities are installed where, and who approved them?

TechRadar's related coverage frames this as an enterprise supply-chain risk. Skills need identifiable authors, versions, review status, permission boundaries, and a single source of truth. That framing is not exaggerated. If a skill can read production logs, run deployment scripts, or access an MCP server containing customer data, the skill is tied to organizational operating authority.

Research is moving in the same direction. SkillsVote examines how long-horizon agent trajectories can become reusable skills, but it also notes that raw trajectories are noisy and that open skill ecosystems can become redundant, uneven, and environment-sensitive. The paper argues for governance across collection, recommendation, and evolution. It sees governed external skill libraries as a way to improve a frozen agent without updating the model, but only if control exposure, credit, and preservation are handled.

The common word across these sources is governance. More skills can make agents more useful. Uncontrolled growth can also pollute context and behavior. If multiple similar skills exist, selection becomes unstable. If old skills remain installed, outdated procedures repeat. If unverified skills enter the system, permission boundaries blur. A skill registry is not just a folder or catalog. It needs policy, evaluation, lifecycle management, and eventually deprecation.

What development teams should decide now

Even teams that never use NVIDIA's own verified skills can take a practical standard from this announcement. First, classify skills as installable capabilities, not casual documents. If a folder contains SKILL.md, scripts, references, and assets, it deserves code review and security review.

Second, require a skill card or equivalent metadata. At minimum, a skill should declare its owner, license, dependencies, supported harnesses, required tools, data access, known limitations, and approval conditions. Without that metadata, enterprise distribution becomes guesswork.

Third, widen scanning from code to natural language. Prompt injection, trigger abuse, excessive agency, and purpose-access mismatch are difficult for dependency scanners to catch. A skill's prose is part of the execution surface.

Fourth, use signatures or hash-based integrity checks. Teams need to know that the skill they reviewed is the skill that was installed. Fifth, keep runtime guardrails separate from installation gates. Pre-installation verification does not remove the need for runtime permissions, and runtime guardrails do not justify installing unverified capabilities.

This applies to internal skills as much as open-source skills. An internal deployment skill, security-log analysis skill, or customer-support response skill may have more privilege than a public helper downloaded from a catalog. If the agent runs under a person's account or can touch CI/CD tokens, cloud credentials, production logs, or customer data, one skill can become an incident path.

Many organizations will start with a reasonable step: "let's write our development rules into AGENTS.md or SKILL.md." That is useful. But once those files accumulate, the next questions arrive quickly. Who approved this? Which projects use it? Does it contain risky instructions? Was it revalidated after it changed? NVIDIA's verified-skill work is one example of institutionalizing those questions before the skill ecosystem becomes too large to inspect manually.

Agent capabilities now need releases

The agent market is moving from model performance to tool connection, and from tool connection to operational control. MCP servers, agent skills, workflow backends, sandboxes, telemetry, approval gates, and registries all point in the same direction. The more work agents do, the more important it becomes to govern how their capabilities enter, change, and retire.

NVIDIA Verified Skills is less a final standard than a clear signal. An agent skill is not documentation. It is a release artifact. It should pass review, scanning, carding, signing, and verification, and organizations should connect that flow to runtime guardrails. The same trust problem will not stay inside NVIDIA's ecosystem. Claude Code, Codex, Cursor, Gemini and Antigravity, OpenCode, and internal agent platforms all accept some form of rules, skills, plugins, extensions, or tool bundles. Once agents can load external capability, the supply-chain question follows.

The competitive axis for agent skills will therefore shift. The important question will not only be "how many skills are available?" It will be "which skills can I trust enough to install?" npm had to grow package metadata, lockfiles, registries, signatures, vulnerability scanning, and provenance discussions. Agent-skill ecosystems are starting down a similar path. NVIDIA putting skill.oms.sig and skill cards at the center is a sign of that transition.

Agent capabilities now need to be released, verified, monitored, and retired like software assets. That is the real meaning of this announcement: the agent's ability to act is itself becoming part of the software supply chain.