Skip to main content
Glama

RIGForge

Don't trust your agents. Prove them.

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.

License: MIT Python CI Works with


See it catch a lie in 5 seconds

pip install -e .   # then:
rigforge demo

Output (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.

Related MCP server: fallimmig-us-mcp

The problem

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 ProofPacket that 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.

90-second quickstart

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-signature

Wiring 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.

Prove it yourself — the honesty benchmark

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 runs

On 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 --leaderboard

Works with your stack

Your 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 auth

Your 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 1

Running a fleet? The swarm verdict board

One 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:

// tools/call → gev.seal_and_verify
{ "agent": "claude-code", "name": "auth refactor", "artifacts": ["src/auth.py"] }
// → { "accepted": true, "integrity_ok": true, "signature_ok": true, ... }

Spec-bound proofs — "did the build match the spec?"

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 clean

Skip 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.

Merge gate — block unsigned proofs before they land

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-signature

The 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.

Public attestation — compose with Sigstore / in-toto / SLSA

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.

Honest scope

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.

How it works

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

CLI reference

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.

Configuration (rigforge.yaml)

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.

Tests

pip install -e ".[dev]"
pytest                           # 252 passing

The 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.

License

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.


Video walkthrough

demo preview

FDE bar (this studio)

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.

Employer entry path

For the shortest false-done demo, start at proof-studio (bash scripts/smoke.sh).

A
license - permissive license
-
quality - not tested
C
maintenance

Maintenance

Maintainers
Response time
Release cycle
Releases (12mo)
Commit activity

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Servers

View all related MCP servers

Related MCP Connectors

  • MCP server teaching AI agents to implement TideCloak: auth, E2EE, IGA, security analysis

  • Control plane for autonomous software labor. Agents claim objectives over MCP with audit trail.

  • Personal MCP server for humans who create. Proof of authorship, license control.

View all MCP Connectors

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mrodgersjs-web/rigforge'

If you have feedback or need assistance with the MCP directory API, please join our Discord server