Bumps the protect-mcp pin from 0.5.5 to 0.7.4 in both review-agent-governance and protect-mcp hooks so the PreToolUse `evaluate` and PostToolUse `sign` verbs resolve and the governance gate runs fail-closed (deny -> exit 2). Rewrites the test suite (init --dir, receipts.jsonl, v2 receipt schema, real Cedar entity shape); 8/8 pass. Verified locally: verbs function on 0.7.4, deny path exits 2, make validate STRICT=1 clean.
Closes#601.
Closes the version-pinning suggestion from @wshobson on #494. The
tamper-detection test in plugins/protect-mcp/test/run-tests.sh
previously called `npx protect-mcp@latest` and `npx @veritasacta/verify`
with no version constraint, meaning an upstream npm publish could
flip the test green or red without any repo-side signal. Pinning
eliminates that.
Changes
───────
- plugins/protect-mcp/hooks/hooks.json: 2 x
protect-mcp@latest -> protect-mcp@0.5.5
(PreToolUse evaluate + PostToolUse sign)
- plugins/protect-mcp/test/run-tests.sh:
6 x protect-mcp@latest -> protect-mcp@0.5.5
3 x @veritasacta/verify -> @veritasacta/verify@0.3.0
(the four PreToolUse test invocations, keygen, sign, plus the two
verify calls in tests 7 and 8)
- Header comment at the top of run-tests.sh now mentions the pinned
@veritasacta/verify version for clarity.
What is NOT pinned
──────────────────
README.md and SKILL.md references remain as `npx protect-mcp@latest`
and `npx @veritasacta/verify`. Those are documentation of the pattern
a user should use in their own project, and "latest" is the right
advice for that audience. The test infrastructure is the only
executed path where pinning matters for reproducibility.
How to bump
───────────
When you want to update (e.g., protect-mcp publishes 0.6.0 with a
breaking change to --input handling), update both files together:
perl -i -pe 's/protect-mcp\@0\.5\.5/protect-mcp\@0.6.0/g' \
plugins/protect-mcp/hooks/hooks.json \
plugins/protect-mcp/test/run-tests.sh
Then re-run ./plugins/protect-mcp/test/run-tests.sh to confirm the
tamper-detection guard still passes before merging.
This PR does NOT touch review-agent-governance or signed-audit-trails
because those plugins are still in review (#495, #496). Once they
land, a follow-up PR will pin them too.
Tests
─────
- python3 -m json.tool hooks.json passes
- bash -n run-tests.sh passes
- No other files touched; no marketplace.json changes (avoids conflict
with #495 and #496)
Addresses #471. Adds the first cryptographic governance plugin to the
marketplace: every Claude Code tool call is evaluated against a Cedar
policy before running, and every decision produces an Ed25519-signed
receipt that anyone can verify offline.
Contents of plugins/protect-mcp/:
- skills/protect-mcp-setup/SKILL.md — full setup + hook config guide
- agents/policy-enforcer.md — Cedar policy author (opus) with example
policies for research, development, and production contexts
- agents/receipt-verifier.md — verifier/chain expert (sonnet) that
diagnoses signature mismatches, chain breaks, and malformed receipts
- commands/verify-receipt.md — /verify-receipt <path>
- commands/audit-chain.md — /audit-chain [--last N]
- hooks/hooks.json — PreToolUse (Cedar evaluate) + PostToolUse (sign)
- README.md + plugin.json
The plugin depends on two published npm packages:
- protect-mcp (10K+ monthly downloads) — the hooks runtime
- @veritasacta/verify — offline receipt verification CLI
Receipts follow IETF draft-farley-acta-signed-receipts, use RFC 8032
Ed25519 signatures, and RFC 8785 JCS canonicalization. Cedar is AWS's
formally-verified authorization engine (the WASM bindings were
upstreamed in cedar-policy/cedar-for-agents#64).
Marketplace entry added under category "security". Category
"governance" does not exist in the marketplace today; happy to propose
one in a follow-up if the maintainer prefers.
TJF