RIGForge catches your AI coding agent when it lies about "done." When an agent
says BUILD COMPLETE ✅, you have its word and nothing behind it. RIGForge replaces
the word with a cryptographically signed ProofPacket — so "the build passed" becomes
something you re-verify with one command, not a message in a chat thread.
pip install -e . # then:
rigforge demoOutput (real — the tamper detection is computed by the same crypto the platform uses):
╭───────────────────────────────────────────╮
│ RIGForge · Live Tamper-Detection Demo │
╰───────────────────────────────────────────╯
1 · the claim An AI agent reports: BUILD COMPLETE ✅
2 · RIGForge seals a signed ProofPacket
packet sha256 7def637005db987daeb020992dd36ef1…
hmac signature 8c80ed299a6298e22e60893af036f4f2…
integrity ✔ valid
signature ✔ valid
3 · the tamper The artifact is TAMPERED and the packet hash is
re-forged to hide it. Naive integrity now PASSES —
the lie looks clean.
4 · RIGForge verify
naive integrity check PASS — fooled by the re-forged hash
hmac signature check FAIL — signature does not verify
🚨 FORGED. Signature invalid. The agent lied.
Nothing in that demo is scripted. Every hash, signature, and verdict is computed by the
same code path that seals and verifies real work. Swap the narration for your own
asserts — the cryptographic outcome doesn't change. The forged seal gets caught because
the HMAC was bound to the original artifact hash, and the attacker never had the signing key.
AI coding agents are fast and confident — and that's exactly the risk. They report success they didn't earn, skip the gate that would've caught the failure, and leave no trail to prove what actually ran. A "✅ done" in your terminal is unfalsifiable. You can't audit a vibe.
RIGForge makes agent output provable:
- Work seals a
ProofPacketthat SHA-256-hashes every artifact and records the exact run environment. - The packet is HMAC-SHA256 signed — tamper the result and re-forge the hash, the signature still fails.
- Verification is a command:
rigforge verify --strict --require-signature. Pass = a signed, re-checkable artifact. Not a message in a thread.
git clone https://github.com/mrodgersjs-web/rigforge.git
cd rigforge
python3 -m venv .venv && source .venv/bin/activate
pip install -e .
rigforge demo # watch it catch a forged "done"
rigforge init # scaffold proofs/, contracts/, ledger/, rigforge.yaml
rigforge run 1 # run a phase's deterministic gate bundle
rigforge seal 1 --artifact docs/PHASE1.md --evidence "bootstrap complete"
rigforge verify --require-signatureWiring it into your own agent? examples/verify_agent_done.py
is the smallest real integration — seal a claim, tamper it, watch the signature catch the lie.
Don't take the README's word for it either. RIGForge ships a seeded, offline, reproducible benchmark that runs forged-proof attack scenarios (tampered artifact, forged signature, swapped artifact, dropped gate, unsigned tamper) and reports the false-done-caught rate — how often the signature check catches a lie that naive integrity misses:
rigforge benchmark # real crypto, deterministic seed, byte-identical across runsOn the default seed it runs 16 scenarios — 8 honest, 8 forged across 5 attack classes — and catches every forged "done" while wrongly blocking zero honest ones:
false_done_caught_rate 1.00 (8/8 forgeries caught — 0 slipped through)
false_pass_rate 0.00 (0/8 honest claims wrongly blocked)
accuracy 1.00 (16/16 verdicts correct)
That 100% isn't a marketing number — it's the point: an HMAC bound to the original artifact
hash is cryptographically unforgeable without the key, so a tampered "done" must fail the
signature check. Every figure is tallied from actual ProofPacket.verify_signature() verdicts,
not hardcoded — read rigforge/benchmark.py and re-run it yourself.
Want to see why each layer matters? The false-done-caught leaderboard scores verification strategies head-to-head — naive integrity catches 0%, signing 67%, spec-bound 100%:
rigforge benchmark --leaderboardYour agent — RIGForge exposes its contract + proof tools over MCP, so Claude Code, Codex, Cursor, and OpenCode can seal and verify proofs directly:
rigforge mcp-serve --transport stdio # preferred by Claude Code et al.
rigforge mcp-serve --auth-token "$RIGFORGE_MCP_TOKEN" # HTTP, bearer-token authYour observability — RIGForge emits OpenTelemetry spans per phase and gate. Point it at your existing collector and traces drop into Langfuse / Phoenix / Jaeger. With no collector set, spans print as OTLP-JSON to stdout. Not installed? It's a clean no-op — the free core never requires it:
pip install -e ".[telemetry]"
OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317 rigforge trace 1One agent, you can eyeball. Twenty-five, you can't. Every seal/verify lands on a per-agent board so you can see — provably — which of your agents to trust and which to reject:
rigforge verdicts # (or open the cockpit at :8770 for the live grid) RIGForge · swarm verdict board (by actor)
┃ actor ┃ accepted ┃ rejected ┃ trust ┃
│ claude-code │ 5 │ 1 │ 83% │
│ cursor-agent │ 3 │ 0 │ 100% │
│ rogue-bot │ 0 │ 4 │ 0% │ ← caught
Agents feed the board with one MCP call — no config, the signing key stays server-side so the agent can't forge its own verdict:
Integrity proves the artifact is unchanged. Spec-bound proofs go further: they prove the build
satisfied the acceptance criteria of the exact spec the agent was given. Bind a spec when you
seal — a spec-kit-style markdown checklist or a YAML
criteria: list — and:
- the criteria are signed into the packet — a dropped or edited criterion breaks the signature;
- verification rejects unless every criterion has a passing gate — even if the artifact is intact;
- a swapped spec is caught by hash mismatch.
rigforge seal 1 --artifact build.out --spec spec.md
rigforge spec-check --proof proofs/phase1_proof.json --spec spec.md
# ✅ spec-check: PASS met: login works, tests pass, lint cleanSkip a requirement and the verdict flips — provably, not on a vibe:
❌ spec-check: FAIL
MISSING: lint clean
Observability shows what happened; eval scores quality; orchestration runs the fleet. Proving build-matches-spec is the part nobody else does.
RIGForge enforces a merge gate: no PR merges unless it carries a valid, signed ProofPacket. This is not a recommendation — it's a CI enforcement point.
In practice: your CI workflow runs rigforge verify --require-signature as a
required check. The agent seals work before opening the PR; the gate re-verifies
the seal on push. An unsigned or tampered proof fails the check, and the PR
stays open.
# .github/workflows/ci.yml — required check for PRs
- name: Verify proof
run: rigforge verify --require-signatureThe signing key stays in CI secrets — the agent never sees it, so it can't forge its own verdict. This is the intended deployment: seal on the agent's machine, verify on the CI runner, key lives nowhere the agent touches.
RIGForge's HMAC signature is symmetric — the same key seals and verifies. That means it proves integrity to you, but a third party can't check it without also getting the key (which gives them the ability to forge). If you need public verifiability — downstream consumers, auditors, or a public transparency log — compose with asymmetric attestation:
| Layer | What it does | RIGForge role |
|---|---|---|
Sigstore (cosign) |
Keyless signing with short-lived certificates + public transparency log | RIGForge decides what is true about the run; Sigstore makes that decision publicly checkable |
| in-toto | Signed attestations about supply-chain steps | RIGForge's ProofPacket is the attestation content; in-toto wraps it in a signed supply-chain layout |
| SLSA | Provenance framework built on in-toto attestations | RIGForge seals the provenance; SLSA carries it through the build pipeline |
A concrete example: seal a phase with RIGForge, then wrap the ProofPacket in a
Sigstore attestation so anyone on your team can verify with cosign verify-attestation
— no signing key exchange required, backed by a public transparency log.
RIGForge does not do asymmetric signing or public attestation natively. It does the part nobody else does — proving the run itself is untampered — and hands off to a mature attestation layer for the public-verifiability half.
See SECURITY.md for the full HMAC limitation and the compose
path.
RIGForge proves integrity and provenance — that an artifact is what the agent claims and that nothing changed it since sealing. It does not make your code correct or safe, force an agent to seal, or survive a stolen signing key. Those boundaries are stated plainly, not buried — full trust model and what it deliberately doesn't defend against: docs/THREAT_MODEL.md.
Work flows through 7 explicit phases. Each phase runs a deterministic bundle of quality gates
(pytest, ruff, schema + config validation — each timeout-guarded). Passing a phase seals a
ProofPacket:
artifact ──SHA-256──▶ integrity hash ──HMAC-SHA256(signing key)──▶ signature
│
rigforge verify ─────────┘ re-checks both. Tamper either → FAIL.
| Phase | Name | What it gates |
|---|---|---|
| 1 | Bootstrap & Doctrine | Repo structure, doctrine docs, hardening |
| 2 | Environment Validation | Python, deps, config checks |
| 3 | Runtime Kernel | Core models, schemas, registries |
| 4 | Control Plane Registries | Agent catalog, build cards, intent maps |
| 5 | GEV Loop + DoneContract | Contract-based verification with proof packets |
| 6 | Archon Harness | Agent orchestration, parallel gate scheduling, budget enforcement, auto-resume |
| 7 | Cockpit | rigforge cockpit — mission-control HTML view |
rigforge init # scaffold a project
rigforge doctor # diagnose env, layout, contracts, CI, lint readiness
rigforge status # phase status (--json for machine-readable)
rigforge run N [--dry-run] # run phase N's deterministic gate bundle
rigforge seal N --artifact PATH [--spec FILE] # seal a phase (optionally spec-bound)
rigforge verify [--strict] [--require-signature] # re-check sealed phases
rigforge spec-check --proof P --spec S # prove a build matched its spec
rigforge resume # resume the most recent failed/unfinished phase
rigforge benchmark # the honesty benchmark (false-done-caught rate)
rigforge demo # live tamper-detection demo
rigforge verdicts # swarm verdict board: per-agent accept/reject + trust%
rigforge trace N # run a phase with OpenTelemetry tracing
rigforge cockpit # serve the mission-control UI (127.0.0.1:8770)
rigforge mcp-serve # expose tools to AI agents over MCP
rigforge contract list|create|validate|inspect--json works everywhere it makes sense. --cwd PATH overrides project-root discovery.
rigforge init scaffolds a typed config (rigforge.config.RigForgeConfig):
| Section | Purpose |
|---|---|
budgets |
Cost / token / runtime ceilings, enforced by the harness |
mcp |
MCP transport (http|stdio), services, bearer-token auth |
scheduler |
Parallel gate scheduling, agent catalog |
signing |
HMAC-SHA256 ProofPacket signing + require_on_verify |
cockpit |
Cockpit UI host/port |
Env overrides: RIGFORGE_SIGNING_KEY[_FILE], RIGFORGE_MCP_TOKEN[_FILE],
RIGFORGE_MAX_PARALLEL_GATES. rigforge doctor validates the file.
pip install -e ".[dev]"
pytest # 252 passingThe suite is adversarial by design: tamper-detection, eval-loop no-spin guarantees, gate timeouts, ledger concurrency, and MCP refuse-by-default are all proven with planted failures — each test fails on the broken code and passes only with the fix in place.
MIT — see LICENSE. Built by RIG (Rodgers Intelligence Group).
⭐ If "prove it, don't trust it" is how you want your agents to work, star the repo — it's the signal that keeps this free core moving.
- Script:
docs/video-script.md - Recording:
assets/demo.mp4(75s captioned) - Preview:
assets/demo.gif
| Practice | Here |
|---|---|
| Employer summary | top of README |
| Smoke proof | bash scripts/smoke.sh |
| Public boundary | docs/public-boundary.md |
| Claim under test | rigforge demo |
| Fleet | profile · resume · patents |
If scripts/smoke.sh fails, treat README claims as false until fixed.
For the shortest false-done demo, start at proof-studio (bash scripts/smoke.sh).
