RIGForge
Enables exporting RIGForge phase and gate traces to Jaeger via OpenTelemetry for monitoring and integrity verification.
Emits OpenTelemetry spans per phase and gate, enabling traces to be sent to an OpenTelemetry collector for observability.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@RIGForgeverify the agent's build complete claim"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
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.
See it catch a lie in 5 seconds
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.
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
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.
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-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.
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 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 --leaderboardWorks 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 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 1Running 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% │ ← caughtAgents 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 cleanSkip a requirement and the verdict flips — provably, not on a vibe:
❌ spec-check: FAIL
MISSING: lint cleanObservability 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-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.
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 ( | Keyless signing with short-lived certificates + public transparency log | RIGForge decides what is true about the run; Sigstore makes that decision publicly checkable |
Signed attestations about supply-chain steps | RIGForge's ProofPacket is the attestation content; in-toto wraps it in a signed supply-chain layout | |
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 |
|
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 |
| Cost / token / runtime ceilings, enforced by the harness |
| MCP transport ( |
| Parallel gate scheduling, agent catalog |
| HMAC-SHA256 ProofPacket signing + |
| 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 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.
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
Script:
docs/video-script.mdRecording:
assets/demo.mp4(75s captioned)Preview:
assets/demo.gif

FDE bar (this studio)
Practice | Here |
Employer summary | top of README |
Smoke proof |
|
Public boundary |
|
Claim under test | rigforge demo |
Fleet |
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).
This server cannot be installed
Maintenance
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
- AlicenseBqualityAmaintenanceAn MCP server that enforces fail-closed deterministic checks, independent refute-first review, and tamper-evident hash-chained receipts for AI agent outputs before claiming completion.Last updated43MIT
- Alicense-qualityCmaintenanceA sovereign, MIT-licensed MCP server for professional-service workflows, providing offline-capable, Ed25519-signed tools for autonomous agents and human developers.Last updatedMIT
- Alicense-qualityCmaintenanceGoverns and audits AI coding agents via command gating, cryptographic logging, and multi-agent orchestration, exposed as an MCP server.Last updated254MIT
- Alicense-qualityAmaintenanceAn MCP server that provides tools for certificate verification, equivalence proving, and pre-registration sealing, enabling AI agents to re-derive verdicts from artifacts rather than trust assertions.Last updatedApache 2.0
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.
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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