# Continuous assurance - a per-checkpoint CI gate - Provael

> Markdown twin of https://www.provael.com/continuous-assurance/ - derived mechanically from the page's own rendered content at
> build time (it can state nothing the page does not). Curated, data-driven twins exist for the
> key pages; this one is generated so the twin convention has no holes.

CONTINUOUS ASSURANCE · PER-CHECKPOINT CI GATE

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

A policy changes with every checkpoint, and so can the way it fails. The checkpoint security gate re-runs the red-team in simulation on each new checkpoint in your CI, compares it with a stored baseline and, when it passes, emits an Ed25519-signed, dated attestation. The gate is free; Provael can also run it for you.

Run for you: the Assurance subscription, $30,000 per year, invoiced quarterly, starts with a short scoping call.

Book a scoping call

Every attack family · free Ed25519-signed · offline-verifiable

How it works

## A gate that keeps its own baseline

The baseline lives in the Actions cache and moves only when a checkpoint passes the gate, so a checkpoint the gate fails never becomes the new baseline. A rise too small to fail the gate passes, and that run becomes the next baseline.

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: there is 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, and each has 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% confidence interval and a benign control.

04

### It diffs against the baseline, and decides under your protocol

The new rate is compared with the baseline on the overall slice and on every critical attack the protocol names. A slice fails the build when it rises by more than the tolerance you set and its confidence interval no longer overlaps the baseline's; so does a release decision of FAIL under the named acceptance protocol. Without a protocol the run is a diagnostic: measured, reported, and no acceptance decided.

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 a regression as step 4 defines it; 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, under a named protocol
provael report --in runs/candidate \
  --baseline .provael/baseline.report.json \
  --regression-tolerance 0.05 \
  --protocol examples/assessment/protocol.example.yml

# 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, every attack, the attack-success rate, SARIF and the GitHub Action are free under Apache-2.0. What Provael charges for is running the red-team for you.

For the person who signs off

## A dated, signed record for each checkpoint

Every passing run leaves a per-checkpoint artifact you can hand to a certifier or insurer, or evaluate for your own robustness documentation. It binds the measured attack-success rate (with its 95% confidence interval), 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. The signature establishes origin and integrity of the envelope - it carries no insurer, assessor or notified-body acceptance, and local signing with your own key is in the free tool.
- Comparable over time. A standing record of the rate at each checkpoint, not a one-off demo.
- Traceable. The diff, the SARIF, and the summary are bound together - one artifact, one signature.

What the attestation is, and is not. It attests that the measured attack-success rate did not regress against the tested attack suite, between two checkpoints, in simulation. It does not prove the policy is safe, does not cover attacks outside the suite, and is not a real-robot result. 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. Provael is a defensive, offensive-security tool for systems you own or are authorized to assess. Evidence, not certification.

CROSSWALK

## What the attestation maps to

[EU MACHINERY REGULATION 2023/1230

Applies from 20 January 2027 and pulls AI-driven safety functions into a cyber-risk assessment. A dated, per-checkpoint attestation is evidence you can bring to that assessment.

See the crosswalk →](https://www.provael.com/compliance/eu-machinery-regulation/) [ISO 10218-1/-2:2025

The 2025 revision makes cybersecurity a "shall" for industrial robots. A continuous attestation of the attack-success rate maps to an input of the 10218-2 system assessment.

See the crosswalk →](https://www.provael.com/compliance/iso-10218/)

See the full [framework crosswalk](https://www.provael.com/compliance/), the [measured defenses](https://www.provael.com/defenses/) the gate can run against, and [the Machinery Regulation page](https://www.provael.com/machinery-regulation/).

Run for you

## When you want Provael to run it

### Assurance subscription

$30,000 per year, invoiced quarterly

Evidence that keeps up with a policy that keeps changing: the red-team re-run each quarter and CI gated on your acceptance protocol, for one annual fee. No subscription has been sold yet, and none is implied.

The price covers one checkpoint line.

### Fleet CI

On request

The same gate across a fleet of policies, run on every checkpoint and scoped with you, the same way as [a red-team assessment](https://www.provael.com/assessment/).

## Put a signed gate on your fleet.

Tell us what you ship and how your CI runs. Either offer starts with a short scoping call.

Book a scoping call [See pricing](https://www.provael.com/pricing/)

---
Canonical: https://www.provael.com/continuous-assurance/