Early Access · v0.6.1

From a recorded run to a gate on your own agent.

Begin with customer-support permissions, not a payment integration. Everything runs on your machine; there is no account. The Stripe walkthrough below is a separate example, not the boundary of the product.

npx rigorrun demo

Start with the Helpdesk twin

A model-free, scripted pair in a simulated two-organisation helpdesk: compare scoped credentials with a broad service token, and read the twin’s access, refund and outbox evidence. No provider key or external account. This illustrates a permission failure; it is not a general-purpose LLM evaluation or a live helpdesk integration.

The pair command exits successfully when the demonstration completes, even when one control fails cases. Its process exit is not a passing candidate release gate.

See the recorded Helpdesk run Scope your workflow
npx rigorrun helpdesk try

For your own HTTP agent, open the local runner, select Helpdesk twin, explicitly review the rules, connect the candidate and inspect the run's system evidence. Repeat the saved project, then use the same suite in a CLI release gate. A verdict applies only to the checked suite and observable environment.

Guided Agent Release Check

A concrete Stripe workflow

  1. 1

    See a recorded run

    Before anything touches your setup: a real run, replayed offline, with what the agent said beside what the system showed. No keys, no account.

    Or read it here 

    npx rigorrun demo
  2. 2

    Try the Stripe pack on the twin

    The twin is a local copy of the part of Stripe’s API the cases use. It runs on this machine, accepts any test key and reaches nothing. Start it, leave it running, and set up the pack against it. Every verdict on the twin says so.

    # terminal 1: the twin, left running
npx rigorrun stripe twin

# terminal 2
npx rigorrun stripe init --twin --yes
  3. 3

    Move to your Stripe test mode

    Give RigorRun a test key of its own; it lives in this machine’s secret store, never in the project. Only test keys are accepted: the key is checked before any request is sent, and Stripe must then confirm it is not in live mode. A dedicated Sandbox, used by nothing else during a run, is recommended.

    export STRIPE_TEST_KEY=sk_test_…
npx rigorrun stripe init --key-env STRIPE_TEST_KEY --safety staging
  4. 4

    Point it at your agent, no code changes

    RigorRun sends each ticket to the endpoint your agent already serves (map your request shape with --body-template), waits for its answer and records the sentence as the agent’s claim, then reads Stripe itself. Your agent keeps its own Stripe test key and never sees RigorRun’s — or, for the local twin, its Stripe base URL points at the twin. The example agent shows the whole contract in one file.

    The example Stripe support agent 

    npx rigorrun agent add --project <id> --name support \
  --black-box http://127.0.0.1:8787/ --claim-path message
  5. 5

    Run the canary

    One small full refund through your agent, end to end, before the full suite: the first verdict you read is about the plumbing, not the policy.

    npx rigorrun stripe canary --project <id>
  6. 6

    Run the gate

    Every ticket, a verdict for each beside what Stripe holds, and an exit code: 0 passed, 1 the agent failed, 2 the setup is wrong, 3 too little could be established to say.

    npx rigorrun gate --project <id> --report report.html
  7. 7

    Put the gate in CI

    The GitHub Action runs the same gate as a step in your workflow, publishes its summary and uploads the HTML report.

    The CI guide 

    - name: RigorRun gate
  uses: Konuktor/rigorrun@v0.6.1
  with:
    project: ${{ vars.RIGORRUN_PROJECT }}

Your own workflow — experimental

Demonstration, rule review and generated diagnostic suites exist. A supported custom permission pack still needs an adapter, safe reset and trustworthy readbacks; connecting an API alone does not qualify it. Discuss feasibility before buying a pilot.

npx rigorrun

  1. Start the runner

    It prints a URL with a single-use pairing code and opens your browser. On a headless box, the printed URL is the whole interface.

  2. Connect your system

    An MCP server you already run, an OpenAPI document, or a web application through a browser. Point it at staging or a scratch instance — RigorRun refuses to write to anything you mark production.

  3. Do the job once

    RigorRun reads your system before you start and again when you finish, and works out what the rules must be from what changed. You rule on each one; a rule you reject cannot fail your agent.

  4. Assess the suite before using a release gate

    Generated suites are diagnostics until current quality evidence establishes that their checks are meaningful. Assessment performs repeated test writes; choose a resettable safe environment and inspect its limits. Custom two-tenant permission packs are not generally available.