Trust is a lifecycle, not a scan
A security scan answers a question about one moment: what did the tool observe in these bytes under this policy? That is useful, but it is not yet a trust lifecycle.
The harder question comes later. The skill or plugin has been upgraded, copied to another machine, or changed by a dependency update. Is this still the artifact someone reviewed, or is it merely an artifact with the same name?
Casefile handles that with a lock-and-verify workflow. A lock records the artifact’s content identity, the operator-owned policy, the active and suppressed findings, and the scanner and report versions that produced the evidence. It deliberately excludes the absolute path and scan time, so moving unchanged bytes to another directory does not manufacture drift.
casefile lock ./plugin \
--out ../plugin.casefile-lock.json \
--config ./casefile-policy.json \
--strict
casefile verify ./plugin \
--lock ../plugin.casefile-lock.json \
--config ./casefile-policy.json \
--strict
Verification does more than compare one checksum. It distinguishes changes to artifact bytes, policy, findings, and tool or report versions. A newly detected capability and a scanner upgrade are both drift, but they are different kinds of evidence and should not be collapsed into one red light.
The policy stays outside the artifact for the same reason. An untrusted plugin cannot be allowed to ship a configuration file that suppresses its own findings. Acceptance belongs to the operator, so the operator supplies the policy again during verification. If those exact policy bytes changed, Casefile reports that too.
There are two limits worth stating plainly.
First, the lock’s digest is an integrity checksum, not a signature. It detects internal tampering, but authenticity depends on where the lock is stored and who is allowed to change it. A reviewed repository or protected release process can provide that trust; the JSON file cannot invent it.
Second, an exact match does not prove behavioral safety. It means the current artifact, policy, findings, and tool identity match the state that was accepted. That is a narrower claim, and a much more useful one than “the scanner says it is safe.”
The pattern applies beyond agent capabilities: approval should attach to identified evidence, not to a name or a memory. Scan once, decide deliberately, lock the accepted state, and make later change impossible to mistake for continuity.