A skills.lock file puts Agent Skills behind the same digest check as an npm dependency

The useful output of a scan is the exit status. The project's safe example file exits 0, and its intentionally unsafe example matches a credential, command, prompt-injection or data-exfiltration rule and exits 1 ^[3]. A third code, 2, is reserved for an invalid command, path or configuration ^[4]. That separation is what makes the check safe to wire into a required CI job, because a typo in your include glob fails differently from a file that passed.

The exit-1 demonstration is a claim about one Markdown file the project wrote in order to fail ^[3]. For it to transfer to your repository, your skills have to contain the patterns the rules enumerate: sensitive local paths, privileged environment variables, embedded private keys, destructive commands, download-and-execute chains, `eval`, encoded execution, reverse connections ^[5]. And your actual threat has to be expressible as a static pattern. Prompt injection is prose, and prose gets rewritten; a jailbreak rule catches the phrasings someone already wrote down.

The MCP side of the rule set is the part I would enable first. It flags raw shell execution, unpinned server packages, and plaintext secrets in `env` ^[6]. Those are configuration facts, and a linter is good at configuration facts. The post's own install commands invoke `npx --yes [email protected]`, pinned ^[7].

Scanning alone only tells you the bytes did not match a rule at that moment, which the post says outright ^[8]. `install` writes the reviewed artifact into `skills.lock` with its SHA-256 digest, package manifest, remote source and publisher provenance ^[9]. `verify` compares installed content against that record, and `audit` re-checks integrity while applying the current policy ^[10]. A rule you add in March therefore gets applied to a skill you installed in January, without refetching it.

Remote installs are where the cost lands on someone else. The command requires a publisher-provided SHA-256, and on a digest mismatch or a policy failure it exits non-zero and does not record the artifact ^[11]. Provenance is a separate flag: a detached Ed25519 signature checked against a local public key ^[12]. The digest tells you whether the bytes changed; the signature tells you who published them ^[13]. Most skills today are a URL in a README ^[1]. A remote skill installed with full provenance needs four things to exist: the file, a published digest, a detached signature, and a key you already trust ^[14].

Adoption constraints are modest. Node.js 22.6 or later, zero runtime dependencies, and `init --profile strict` generates a policy file plus a GitHub Actions workflow ^[15][16]. Directory scans discover Markdown skills and common MCP configuration formats, narrowed by include and exclude globs ^[17]. Reports are redacted by default, so the scan does not print the credentials it went looking for ^[18].

The diagnosis and the product come from the same place: a post published on dev.to under the AgentWarden project ^[19]. It does not cite any measured incidence of malicious skills in the wild. The four gaps it names are checkable against your own repository in about a minute, which is the honest way to test the claim ^[2]. Look at how a skill got into your agent's directory, and whether anything in your pipeline would notice if that file changed tonight.

The author is also clear about the boundary: this is a static gate, not a sandbox, and it makes no promise about runtime behaviour ^[20].