Surface provenance, authenticity, and legality of a skill — at import, on demand, and continuously

[Ronen-Levy]

Problem

When a user imports a skill into the Skillberry Store (e.g. from a GitHub URL or Anthropic), they currently make a trust decision with almost no context about the skill's "background." They see what the skill is, but not where it came from, who published it, whether it's legally safe to redistribute, or whether the bytes being imported are genuine and unmodified.

This matters because an imported skill is then re-exposed by the store (via the API, MCP frontend, vNFS, etc.) to downstream agents and users. The store effectively vouches for it. Today that vouching happens blind:

• A skill from a verified, widely-used org is indistinguishable at import time from a two-day-old anonymous fork.
• A skill with no license (all rights reserved) looks identical to a permissively-licensed one — yet only one is safe to redistribute.
• There's no record of the exact upstream commit imported, so the import isn't reproducible and later upstream tampering can't be detected.
• There's no signal about what the skill actually reaches out to or runs, so even a reputable-looking skill could behave unexpectedly.

Just as important: a skill's background is not static and is not only relevant at import time. The upstream source can change after import — the repo can be deleted or made private, the license can change, the maintaining org can lose verification, the pinned content can drift from what was originally imported, or new risky behavior can be introduced. A trust decision made once, at import, silently goes stale.

The result is that the importer has no structured basis for confidence, the store has no durable record of an artifact's origin, and there is no way to learn that a skill's standing has changed after the fact.

When these checks need to run

The same underlying background information is needed in three distinct situations, and the system should support all of them:

1. Before an import is finalized (pre-import). Show the background to the user so they can give informed consent before completing the import — and/or let the store automatically allow/deny the import against a configurable confidence threshold (e.g. block unlicensed or unverified sources).
2. On demand for an already-imported skill (post-import). A user who previously imported a skill — possibly before this capability existed, or who simply wants reassurance — can ask the store to (re)gather and display the skill's background at any time.
3. Continuously / automatically (drift detection). A background process periodically re-checks imported skills and flags when their provenance, authenticity, or legality has changed since import — content drift from the pinned commit, a license change, a source that disappeared or went private, a reputation/verification change, or newly introduced risky behavior.

Who is affected

• The person doing the import — needs enough context to give informed consent before trusting a third-party skill.
• A user revisiting an already-imported skill — needs to retrieve its background after the fact, or be alerted when it changes.
• The store operator / downstream consumers — inherit whatever was imported, need an auditable trail of where each skill came from, and need to know when a previously-trusted skill's standing changes.

Desired outcome

The store should be able to produce a concise, scannable summary of a skill's background — usable to inform a person, to feed an automated allow/deny decision, and to compare against a previously-recorded baseline to detect change. At minimum it should answer:

1. Where did this come from? — exact origin coordinates (repo, ref/path) pinned to the specific commit imported, so the import is reproducible and drift-detectable.
2. Who published it, and is the source reputable? — author/owner identity, whether the org is verified, repository signals (age, popularity, maintenance recency).
3. Is it legally safe to use and redistribute? — detected license and a plain-language read of its obligations, including an explicit flag when no license is present.
4. Is this the genuine, unmodified artifact? — content integrity (a recorded hash of what was imported) and any available authenticity/signing signals.
5. What will it do? — disclosure of external endpoints it contacts, sensitive operations it performs, and third-party dependencies it pulls in.

This should roll up into a single at-a-glance confidence indicator, with the underlying detail available on demand. The information captured at import should be retained as a baseline, so that on-demand and continuous re-checks can be expressed as a diff against it ("license changed from MIT → none", "content drifted from commit a1b2c3").

Out of scope (for this issue)

• The mechanism for gathering and rendering this information (plugin vs. core, which APIs, UI layout).
• The specific scheduling/triggering mechanism for the continuous checks.

Open questions

• In pre-import gating mode, what is the threshold model — block, warn, or annotate — and is it operator-configurable per dimension (e.g. hard-block on missing license, soft-warn on low stars)?
• For drift detection: which changes warrant an alert vs. silent record, how often should re-checks run, and how is the user notified?
• Where should the captured baseline provenance live so it's auditable and diff-able later?
• Should on-demand and continuous re-checks share the exact same evaluation as pre-import, to guarantee comparable results?

[github-actions]

🤖 Automatic Labeling

Bob Shell has analyzed this issue and applied the following label(s): enhancement, security, automation

These labels were selected based on the issue content and available label descriptions. If you believe the labels are incorrect, feel free to modify them manually.