Question-led guide · how-to
How do you verify that an agent skill is the release you reviewed?
Verify a skill package by binding reviewed source, builder provenance, evaluation evidence, and signer identity to the exact artifact being installed.
Direct answer
Verify the downloaded skill's digest, then require source, build provenance, evaluation evidence, and signature identity to refer to that same release subject. Include instructions, references, scripts, and assets in the package inventory. A valid signature establishes an endorsed artifact under a trust policy; it does not establish that the artifact is benign, compatible, or the one your evaluation tested.
Begin with the archive being installed
A review usually examines source files, while a user installs an archive or a host-managed deployment object. The gap between those objects is where generated resources, stale helper binaries, local files, or a repackaged upload can enter. Start verification from the retrieved package and work backward to the evidence supporting it.
Compute its identity using defined packaging rules. If two hosts require different deployment archives, give each an identity and preserve the mapping to the canonical release. Different bytes should not be hidden behind one convenient label.
Inventory everything that can influence behavior
Instructions are only one input. A reference can change a decision rule; a template can change a required output; a helper can introduce an unexpected dependency. Include all material files in the release subject or identify externally resolved dependencies explicitly.
Define treatment of symlinks, executable modes, hidden files, and generated content. Otherwise two teams may compute the same conceptual “version” while reviewing different effective packages. The inventory should also identify licenses and origins for material included from third parties.
A corrected reference misses the evaluated archive
Imagine a hypothetical archive named contract-review-2.4. A reviewer approves a source change correcting a renewal-notice reference. The evaluation service tests the newly built archive, but a manual upload installs yesterday’s archive under the same display label.
Both packages are signed by a recognized identity. Neither signature detects the operational mix-up by itself. The installation verifier must compare the retrieved digest with the evaluated digest and the approved build output. A mismatch blocks activation even though every individual record looks plausible.
Join release evidence by subject
Use this table as an admission review artifact. The entries describe checks to implement and are not claims of an existing certified skill profile.
| Evidence | Must join to | Reject when |
|---|---|---|
| Retrieved archive | Recomputed package digest | Bytes do not match requested subject |
| Build provenance | Source revision, builder, output digest | Builder is not trusted or output differs |
| File inventory | Exact archive contents | Influential files are absent or unexpected |
| Evaluation attestation | Same digest and tested host profile | Tests refer to another candidate |
| Signature bundle | Subject and expected signer identity | Verification fails or signer is unauthorized |
| Admission decision | Policy version and current eligibility | Required evidence is missing or release is revoked |
| Host deployment receipt | Installed object and selected release | Upload mapping cannot be established |
The joins carry the assurance. A folder full of evidence files is weak if none of them identify the same artifact.
Ask provenance and signatures different questions
SLSA provenance supplies the mechanism for tracing production of an artifact. The skill-specific questions include whether the builder packaged the reviewed references and whether an adapter changed the deployment material.
Sigstore’s verification documentation shows how identity and issuer expectations participate in signature verification. Configure those expectations from trusted local policy, not from the package asking to be admitted. An attacker should not be able to choose the identity that counts as authorized for its own release.
Verify before activation, then retain the receipt
Fetch the artifact by immutable identity, validate its evidence, and record the admission decision before making it discoverable to users. Store the installed host object identifier alongside the source release. If a host exposes no digest or equivalent verification surface, document that gap rather than claiming exact byte equality.
Keep evidence after rollout so a later advisory can identify affected installations. Revocation changes current eligibility; it does not erase the historical record or prove that already executed actions were undone.
Separate authenticity from behavioral acceptance
A malicious instruction can have impeccable provenance. A correct package can fail under a new host profile. Preserve behavioral evaluation and operational monitoring as separate controls with their own scope and limitations.
Use behavioral versioning to define what compatibility means, and controlled skill improvement when an automated author creates candidates. Skills in Production connects these mechanisms across the lifecycle. This guide and its archive scenario are independently authored for the website.
Evidence
SLSA provenance connects an artifact to verifiable information about where and how it was produced.
SLSA distinguishes provenance records that trace build outputs and source creation.
Primary source · standard · checked Sep 8, 2026
Limit: Applying this mechanism to a skill archive is architectural transfer and does not establish SLSA conformance.
Sigstore verification can check artifact signatures against an expected certificate identity and issuer.
The Cosign documentation describes identity-based verification and blob bundles containing certificates and signatures.
Primary source · official-doc · checked Sep 8, 2026
Limit: Successful cryptographic verification does not establish the quality of instructions, test coverage, or authorization to install a release.
The installed skill, evaluated subject, and reviewed build output should be connected by immutable identity.
The release evidence join table makes mismatched subjects and unauthorized builders explicit rejection conditions.
Signal Studio author framework · reviewed Sep 8, 2026
Limit: The table is a proposed skill admission procedure and still depends on trustworthy builders, evaluators, keys, and local policy.
Limitations
Artifact verification protects identity and evidence relationships. It cannot prove that trusted maintainers, builders, or evaluators are uncompromised, nor that a correctly identified skill will behave safely in an untested environment.
FAQ
- Is a repository commit enough to identify an installed skill?
- Not necessarily. Packaging can include generated files, uncommitted local content, or downloaded resources. Record the source commit and the resulting package digest, then verify their relationship through the build evidence.
- Can I trust every skill signed by a known maintainer?
- A trusted signature is one input. Installation still depends on intended scope, current eligibility, dependency inventory, applicable evaluation, and the authority of that signer for the particular release.
Related guides
Continue within Agent skills in production, or use one of these adjacent diagnostics:
Editorial QA: automated native-English, structure, source-presence, and link checks completed . This record is not an independent expert endorsement. Review boundary.