STALE MEASUREMENTOur published benchmark result was measured with v0.32.0, 9 releases ago. That is our own number, not your assessment, which runs against your policy on the current release. Why, and what unblocks it

ProductEvidenceTop 10LeaderboardCompliancePricingDocsStar on GitHub Quickstart
CONTINUOUS ASSURANCE · PER-CHECKPOINT CI GATE

Every checkpoint, re-red-teamed. Every run, signed.

A policy is not a fixed artifact - it changes with every checkpoint, and so does its attack surface. Provael's checkpoint security gate re-red-teams each new checkpoint in your CI, diffs its attack-success rate against a stored baseline, and emits an Ed25519-signed, dated attestation that the policy did not regress against the tested attack suite. Self-maintaining, offline-verifiable, defensive and simulation-only.

Every attack family · freeDefensive · sim-onlyEd25519-signed · offline-verifiable
How it works

A self-maintaining gate, not a one-off test

The baseline lives in the Actions cache and updates itself only when a checkpoint passes - so the bar ratchets forward on its own, and a regression can never quietly become the new normal.

01

A new checkpoint lands

On every push of a new model checkpoint, the reference GitHub Action restores the stored baseline report from the Actions cache. The baseline travels with the repo - no server to run.

02

It checks the checkpoint before loading it

Before any policy is instantiated, the gate verifies the checkpoint against a digest you pin and refuses pickle-format weights - both fail closed, each with an explicit opt-out that is recorded in the evidence rather than being silent. Loading a pickle executes it, so the check is worthless after the load. This is a supply-chain control: it produces a pass/fail verdict, not an attack-success rate, and it does not reduce one.

03

CI re-red-teams it

Provael runs the same attack suite against the new checkpoint in simulation and produces a fresh attack-success rate with its 95% Wilson confidence interval and a benign control.

04

It diffs against the baseline

The new ASR is compared to the baseline within a regression tolerance you set. A regression beyond tolerance fails the build; nothing is promoted.

05

It signs and promotes

When the gate passes, Provael emits an Ed25519-signed attestation - a tamper-evident, dated envelope binding the diff, its SARIF, and a human summary under one signature - and promotes the run to the new baseline. The checkpoint digest, its format and the verification verdict ride along in the same evidence pack, nested under their own key so nothing there can be read as a rate.

For the engineer

Wire it into a fleet of policies

Drop the reference workflow into each policy repo (or matrix it over a fleet of checkpoints). The gate fails the build on an ASR regression beyond your tolerance; the provael[attest] extra adds Ed25519 signing (--no-sign gives a digest-only bundle). Any attestation verifies offline.

# reference GitHub Action
.github/workflows/checkpoint-security-gate.yml

# gate a candidate run against the baseline
provael report --in runs/candidate \
  --baseline .provael/baseline.report.json \
  --regression-tolerance 0.05

# emit a signed regression attestation
provael attest --policy <policy> --suite <suite> --out runs/attest

# verify any attestation offline
python -m provael.regression.verify_regression_attestation

The CLI, the attacks, the ASR, SARIF, and the GitHub Action are free and Apache-2.0 under the open-core promise. The paid surface is operated assurance, never a feature paywall.

For the person who signs off

A dated, signed record - not a screenshot

Every passing run leaves a per-checkpoint artifact you can hand to a certifier or insurer, or evaluate for inclusion in your own robustness documentation. It is candidate evidence toward a technical file, not a conformity assessment, and whether it belongs there is your decision and your notified body's. It binds the measured attack-success rate (with its 95% Wilson CI), the SARIF, and a human summary under one Ed25519 signature, dated and verifiable offline.

  • Dated & signed. A tamper-evident envelope, timestamped per checkpoint.
  • Offline-verifiable. Anyone can check the signature without contacting a server; the signer key is untrusted by default until you trust it out of band.
  • Comparable over time. A standing record that robustness held between checkpoints, not a one-off demo.
  • Traceable. The diff, the SARIF, and the summary are bound together - one artifact, one signature.

Put a signed gate on your fleet.

Bring your policies and CI, and we will scope a per-checkpoint red-team gate and the signed attestation trail that goes with it - the same scoping flow as an assessment.