Companion to iter-30's mcp-policy.json. Hand-authored Merkle-style
manifest pinning the sha256 of the two security-critical files that
mcp-policy.json governs:
.harness/mcp-policy.json → sha256 (iter-30's MCP governance policy)
.claude/settings.json → sha256 (declares the claude-flow MCP server)
POSTURE IMPROVEMENT (verified end-to-end against metaharness@0.1.14)
BEFORE iter 32 AFTER iter 32
composite oia-audit low CLEAN ★
threat-model worst low (unpinned-deps info (only "no issues
dropped iter 31) found" info note)
mcp-scan findings 0 (iter 31 cleared) 0
L7 governance text "mcp-policy.json "mcp-policy.json
(witness missing)" (witness missing)"
★ Composite worst severity now CLEAN — ruflo's audit pipeline reports
zero non-info findings. iter-7 + 27 + 30 + 31 + 32 closed the full
loop: instrumentation found a HIGH, fix-cycle drove it down to
clean over five iterations.
THE WITNESS GAP (intentionally not closed in this iter)
The OIA "implementation" note still reads "mcp-policy.json (witness
missing)". A witness.json would require Ed25519 signing the manifest,
which needs a WITNESS_SIGNING_KEY (64-char hex). Ruflo's existing
brain-signing-key in GCP is in a different format (89 chars). Three
options documented in .harness/README.md:
1. Provision a new GCP secret `witness-signing-key` (32 random
bytes hex). Requires explicit user authorization — creates a
new long-lived secret. NOT done in this iter.
2. Use a hardware key (YubiKey / Sigstore ephemeral identity).
3. Skip the witness — keep the "(witness missing)" note. Threat
model + mcp-scan are already CLEAN; the witness only signs the
manifest, doesn't add new security controls.
Current state is option 3 by default. Switch to (1) or (2) when
external manifest-verification becomes needed.
SMOKE STEP 17u
- manifest.json exists + parses
- Both security-critical files fingerprinted with valid 64-hex sha256
- README.md exists + documents witness-signing-key option
- ADR-150 anchor present in README
Smoke: 36 → 37. Fleet: 33/33.
Co-Authored-By: RuFlo <ruv@ruv.net>
