What Integrity Can Prove—and What It Cannot

The distribution lifecycle determines which Agent Skills bytes are fetched; integrity controls determine what the repository is willing to expose or write after that choice. The useful question is not whether the system is simply “secure.” It is what each check establishes: whether a complete file set matches its registry hash, whether a requested path remains within an allowed boundary, whether a staged revision is deliberately created, and whether any of those facts say anything about the safety of the advice or command that follows.

Correspondence and containment are different checks

The aggregate content hash answers a correspondence question. The registry declares a skill's files and an expected hash. The MCP server fetches the complete set before returning the main instructions, reference text, or staged execution files. It recomputes the aggregate hash from the bytes it received and rejects a mismatch. If the values match, the client has evidence that the fetched files correspond to the file set and identity advertised by the registry.

That claim includes more than the visible instruction body. A skill may contain references, scripts, templates, or assets whose contents affect how an agent works. Verifying the whole set prevents a client from treating SKILL.md as the only meaningful payload. A changed reference can alter the practical guidance even when the main instructions are unchanged; a changed script can alter what happens when a user later runs it. Whole-set verification makes those files part of the identity the client is checking.

A matching hash is still a bounded fact. It does not show that the bytes are wise, current in the relevant domain, free of manipulative instructions, or appropriate for a particular project. It does not independently authenticate the registry publisher or certify a third-party author's rights. It says that the content received is the content the registry expected. That is valuable for detecting an incomplete, modified, or out-of-sync payload, but it is not a semantic safety certificate.

It also does not remove the need to verify the whole set before returning any part of it. Returning SKILL.md first and checking a reference later would let an agent begin acting on a package whose supporting material had not yet been established as complete. The MCP implementation instead treats the file set as one integrity unit, even when the response exposes only the main instructions or one selected reference. The response can remain small without weakening the identity check behind it.

Path validation answers a different question: where may a file be requested or written? The fetcher accepts only reference paths that appear in the registry's declared file list. The staging path checks reject absolute paths, drive-letter forms, backslash separators, null bytes, empty or dot segments, and traversal segments. The resolved destination must remain inside the intended skill directory.