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.
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.
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.
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.
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.
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.
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.
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_attestationThe 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.
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.
What the attestation maps to
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 →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 →See the full framework crosswalk, the measured defenses the gate can run against, and the Machinery Regulation page.
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.
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.