Provenance, pinning, and updates

A review belongs to a specific state

A useful review identifies the package content and the environment assessed. It does not grant trust to every future package carrying the same name. A source URL, commit or version, file inventory, dependency state, and permission profile help establish that reviewed state.

Provenance asks where an artifact came from and how it reached you. Integrity asks whether its bytes match a recorded value. Neither alone establishes that the content is safe.

What to pin

Record the skill revision, distributed archive, supporting resources, dependency lock state, and any remote content that materially drives behavior. Where a resource cannot be pinned, document who can change it and what approval is required when it changes.

A hash of the entry file says nothing about a script outside that file. A signed package can still contain a dangerous design. Match the control to the property it actually proves.

Classify changes by effect

• Scope: new tasks, broader activation, or different output destinations.
• Authority: new files, credentials, tools, or external services.
• Execution: new scripts, dependencies, or installation behavior.
• Content: revised references that alter a procedure.
• Environment: a host change that makes additional capabilities available.

Even a small text diff may introduce a consequential new prerequisite. Review semantics and data flow, not only the size of the change.

A change-review workflow

1. Fetch the proposed state into an isolated review area.
2. Compare it with the last approved state.
3. Update the file and authority maps.
4. Run the legitimate task and boundary tests.
5. Record reviewer, decision, and unresolved issues.
6. Promote the exact reviewed artifact; retain a rollback copy.

Revocation and rollback

Have a way to disable a package by identity and revision. A rollback is incomplete if leaked credentials remain usable or changed external records stay in effect. Keep artifact rollback, credential revocation, and effect recovery as separate response steps.

Skill lifecycle research treats evolution as part of the attack surface. Incorporate review into updates instead of assuming a one-time installation check is enough.

Worked example: the same version label returns new bytes

An internal catalog identifies a skill as version 1.2. A later download under that label contains a different script and a new external reference. The label is familiar, but it no longer identifies the reviewed artifact. A successful earlier run cannot establish the safety or scope of this changed package.

Work through the evidence

Compare content identities, not just names. Record the source, revision, artifact hash, dependency state, host configuration, and remote resources material to the decision. Review added destinations and permissions even if the change is described as a bug fix. Separate a metadata correction from a new executable path or a changed output recipient.

Decision criteria and a useful review record

Promote an exact artifact after the relevant review, and retain the prior approved state for rollback. Rollback restores selected files or configuration; it does not retract data already sent or undo all external changes. Name an owner for withdrawal, cached copies, and dependent workflows. Treat unavailable provenance as an explicit uncertainty rather than an invisible exception.