A SKILL.md, CLAUDE.md, rules file or prompt pack steers a model with near system-prompt privilege — yet ships as plain markdown anything can silently edit. ContextLock gives those files the same authenticity and integrity guarantees software already expects of packages and binaries, checked before they reach the model.
Git proves history, not provenance. A commit says “this content entered this repo,” never who authored it or whether it matches what a publisher released. The highest-value files — ~/.claude/CLAUDE.md, global skills, plugin caches — live outside any repo entirely: mutable, invisible, implicitly trusted.
Worse, prompt injection can persist. An injected agent appends a line to its own CLAUDE.md and the compromise survives every future session — the agent-world equivalent of malware writing to a startup script. This is no longer hypothetical.
“Require cryptographic signatures (ed25519) on all published skills; reject unsigned installs.”
OWASP Agentic Skills Top 10 — AST01, Malicious Skills
The Agent Skills spec — adopted by 40+ clients — defines no integrity or signing mechanism at all. That silence is the gap ContextLock fills. And because adaptive attacks bypass content-scanning defenses 78–93% of the time, prevention beats detection here: ContextLock doesn’t judge content, it makes tampering and impersonation detectable no matter how clever the payload.
Publishers seal a package into a signed manifest. Users pin the keys they trust. Every time a protected file loads, the engine re-checks the whole chain before a single byte reaches the model — then allows, warns, or blocks by policy.
Signature valid, rollback & expiry pass, hash matches.
File content or length changed since it was signed or sealed.
No envelope, unknown signer, or a file the manifest never listed.
Each guarantee is a named threat with a concrete mechanism. Nothing here judges whether content is safe — only whether it is authentic and unchanged.
The honest boundary: ContextLock hardens the distribution and persistence channels. A same-privilege attacker with code execution as you can re-seal local state — the managed tier moves that goalpost to admin privilege; beyond it is EDR territory, and the spec says so. Full model in SPEC §4.
Pick the ceremony that fits. All three produce the same three verdicts and compose freely.
Reviewed a file you can’t get signed — your own ~/.claude/CLAUDE.md? Pin its bytes locally. Any later edit reads as modified. Zero publisher, zero keys.
Publisher signs with a raw Ed25519 key; users pin the public key or a rotatable, revocable root. Works fully offline. A reviewer can countersign — demand a threshold of signers.
No key to hold. Sign in GitHub Actions; users pin the workflow’s OIDC identity, exactly like npm provenance. Verification is fully offline against a pinned trusted root.
# trust a publisher, then verify before use $ npm i -g @contextlock/cli-user $ contextlock trust add "Acme Security" ./acme-public.key $ contextlock verify ./skills/acme/SKILL.md ✓ trusted (publisher: Acme Security, key: cl-acme-2026) # install a package: verify EVERYTHING, or write nothing $ contextlock install ./downloads/acme-skills \ --dest ./.claude/skills/acme
# one command: keygen + manifest + DSSE signature $ npm i -g @contextlock/cli-publisher $ contextlock-publisher protect ./my-package \ --sign --name "Acme Security" --version 1 generated key · fingerprint c8e4b7d5… wrote contextlock.dsse.json · 2 files sealed # a reviewer can countersign the exact bytes $ contextlock-publisher countersign \ ./my-package/contextlock.dsse.json --key reviewer.key
Every @contextlock/* package publishes to npm with a provenance attestation. Full API, CI recipes and integration guides in the README and SPEC.
Verified means authentic and unmodified — not safe. A trusted publisher can still publish harmful instructions. ContextLock establishes provenance, not content safety. It does the prevention half, deliberately, and composes with the scanning you already run.