Open-source software for EU AI Act Article 57 sandboxes
Sealed model. Sealed data. Signed evidence.
Test a high-risk AI system at your own HPC centre without anyone handing over the model or the data, and keep evidence a notified body can re-check offline.
One test run, from the signed plan to the verified bundle
The film
One supervised test run on a cluster
- A biased age-estimation model is caught
- A corrected one passes
- A hostile model is contained
- The evidence is verified offline
For you
Each party keeps what is theirs
Sign the plan, watch the run, and verify the result yourself, offline.
market-surveillance and data-protection authorities
- Sign the test plan with the provider before anything runs.
- Watch each run in the console; halt it if you must.
- Sign the exit report and verify the bundle offline.
You never see: the model's weights.
Have a model tested without handing over its weights or receiving the test data.
the provider of the model under test
- Sign the same test plan as the authority.
- Commit the model sealed; the plan pins its digest.
- It runs isolated at the host, decrypted only inside the harness.
You never see: the held-out test set.
Host confidential tests as ordinary project jobs, nothing installed as root.
HPC centres, AI Factories and TEFs
- Run the harness as an ordinary project user: Slurm with Apptainer.
- No network from the job: reaching out is dropped and logged.
- At exit the keys are destroyed and the data cannot be decrypted.
The limit: root on the node is the centre's undertaking, not cryptography.
Run the verifier yourself, offline, against anchors you hold. One changed character fails it.
the authority, and later a notified body
- Hold the plan digest, the ledger head, the timestamp authority's root.
- Run histor verify on your own machine, offline.
- Read what the bundle proves and what it does not.
You never see: the test data.
examples/sample-participation/evidence-bundle
VERIFIED — 21 checks passed, 7 warning(s)
examples/tampered/ledger-one-char-edit/evidence-bundle
FAILhash_chain: is the ledger hash chain intact, with no gaps?
entry 15 (gate_decision) does not hash to its stated entry_hash: its
contents were altered after it was written
NOT VERIFIED — 2 check(s) failed
Every line, verbatim
ok bundle_version: is this a bundle format this verifier knows how to check?
bundle_version 0.3
ok bundle_format: is the bundle's format the one its ledger was written for?
bundle_version 0.3, as the ledger's report_generated (seq 25) records
ok signing_keys: was every statement checked under a key the ledger recorded or you gave, not one read from public-keys.json alone?
control-plane (given by you), harness (given by you)
ok signatures: is every attestation the one the ledger recorded, signed by the control plane?
2 attestation(s), each the one the ledger recorded for its run, verify
under the control plane's key
ok statement_types: is every signed statement of a type this verifier knows?
4 statement(s), each of a known type under https://historlabs.eu/
ok hash_chain: is the ledger hash chain intact, with no gaps?
27 entries, chain intact
ok run_numbers: was every run started once, and ended in the ledger, with no unrecorded runs?
runs [1, 2], contiguous, each started once and ended in the ledger
ok plan_versions: is every plan version the ledger records present in the bundle?
2 version(s) — the plan was amended during the participation
warn plan_signatures: was the plan signed by each party, through their own identity provider?
the plan was signed with keys the sandbox holds, not through the
parties' identity providers: the bundle shows that the sandbox signed
it, not who agreed to it
warn report_signature: was the exit report signed by the regulator, through their own identity provider?
report sha256:eb92d315df53… is signed through the development IdP, which
issues a token for anyone: the signature identifies nobody
ok artifact_digests: do the artifacts in every run match the pins of the plan it cites?
2 run(s) match the plan's pins
ok dataset_commitments: was every dataset used committed before the run that used it?
1 committed
warn isolation: is isolation evidence present and does it match the plan's policy?
NO ISOLATION WAS ENFORCED. Every run in this bundle was executed as
ordinary processes on one host. The results describe what the model
answered; they establish nothing about whether it could have reached the
data or the network. This bundle is a development artefact and is not
sandbox evidence.
ok run_logs: do the run logs in the bundle match the digests their attestations carry?
4 logs match their digests
ok harness_statements: did the harness sign what it measured, and does the attestation agree?
2 run(s): the harness signed its measurements and the attestation agrees
ok thresholds: does every stated outcome follow from the numbers reported with it?
recomputed and consistent
warn sample_sizes: were any thresholds passed on samples too small to mean anything?
2 group(s) fell below the plan's minimum and were not scored: run 1
accuracy_by_group mae age_band=18_24 (n=9), run 2 accuracy_by_group mae
age_band=18_24 (n=9)
ok deletion: were keys destroyed after exit?
keys destroyed after exit: ['data/demo-001/lab-heldout-v1']
ok completeness: does the ledger end as a participation that has ended does?
exit, keys destroyed, the report and the regulator's signature over it,
and the report's bundle digest matches this bundle up to seq 24
warn timestamps: are the timestamps valid, ordered, and external?
every timestamp was issued by the sandbox operator's own development
authority, not by a third party. The ordering is self-consistent and
anchors nothing: an operator able to rebuild this ledger could reissue
these timestamps with it.
warn tsa_revocation: was the timestamp authority's certificate unrevoked when it stamped?
no RFC 3161 timestamp in this ledger, so no authority certificate whose
revocation could be checked: development timestamps carry none
ok personal_data: does the manifest say what personal data the bundle holds?
as the manifest says, the bundle holds personal data: staff identifiers
(7, in ledger.jsonl, plan.json, plans/); idp id tokens (1, in
ledger.jsonl), and no test-subject data (none of the files the export
writes can carry it)
ok i18n_catalogues: is the catalogue each translated rendering of the report was made with in the bundle, as the ledger records it?
the report was rendered in English only: no catalogue to carry
ok report_renderings: is the exit report rendered in every language the plan names, each rendering named by hash in the authentic report?
the plan names no languages: one report, in English
ok anchor_plan_digest: is every plan in the bundle one whose digest you hold?
2 plan version(s), every signing and every run match the digest(s) you
gave
ok anchor_sandbox_id: is this bundle the participation you were told it is?
manifest, ledger, plans and runs: demo-001
warn anchors: were the trust anchors given from outside the bundle?
the timestamp authority's root, the identity providers' keys, the
network policy digest, the harness image digest, the audience the
parties' IdP logins were for, the ledger head came from the bundle
itself: the checks against them show that the bundle agrees with itself,
not that it is the one you signed. An operator who rebuilt it could have
replaced them all consistently. Pass them from outside, with --anchors
or the --expect-* options.
ok bundle_digest: does the bundle match the digest in its own manifest?
sha256:86b3110fde8f24e9de897c200c96b8f60edb6b190e08fc5c7ea1e610a4a65a45
VERIFIED — 21 checks passed, 7 warning(s)
Anchors given from outside: plan_digest, sandbox_id, signing_keys
Anchors read from the bundle: tsa_root, idp_keys, policy_digest, harness_digest, audience, ledger_head
What this bundle does NOT establish:
- plan_signatures: the plan was signed with keys the sandbox holds, not
through the parties' identity providers: the bundle shows that the
sandbox signed it, not who agreed to it
- report_signature: report sha256:eb92d315df53… is signed through the
development IdP, which issues a token for anyone: the signature
identifies nobody
- isolation: NO ISOLATION WAS ENFORCED. Every run in this bundle was
executed as ordinary processes on one host. The results describe what
the model answered; they establish nothing about whether it could have
reached the data or the network. This bundle is a development artefact
and is not sandbox evidence.
- sample_sizes: 2 group(s) fell below the plan's minimum and were not
scored: run 1 accuracy_by_group mae age_band=18_24 (n=9), run 2
accuracy_by_group mae age_band=18_24 (n=9)
- timestamps: every timestamp was issued by the sandbox operator's own
development authority, not by a third party. The ordering is
self-consistent and anchors nothing: an operator able to rebuild this
ledger could reissue these timestamps with it.
- tsa_revocation: no RFC 3161 timestamp in this ledger, so no authority
certificate whose revocation could be checked: development timestamps
carry none
- anchors: the timestamp authority's root, the identity providers' keys,
the network policy digest, the harness image digest, the audience the
parties' IdP logins were for, the ledger head came from the bundle
itself: the checks against them show that the bundle agrees with itself,
not that it is the one you signed. An operator who rebuilt it could have
replaced them all consistently. Pass them from outside, with --anchors
or the --expect-* options.
ok bundle_version: is this a bundle format this verifier knows how to check?
bundle_version 0.3
ok bundle_format: is the bundle's format the one its ledger was written for?
bundle_version 0.3, as the ledger's report_generated (seq 25) records
ok signing_keys: was every statement checked under a key the ledger recorded or you gave, not one read from public-keys.json alone?
control-plane (given by you), harness (given by you)
ok signatures: is every attestation the one the ledger recorded, signed by the control plane?
2 attestation(s), each the one the ledger recorded for its run, verify
under the control plane's key
ok statement_types: is every signed statement of a type this verifier knows?
4 statement(s), each of a known type under https://historlabs.eu/
FAIL hash_chain: is the ledger hash chain intact, with no gaps?
entry 15 (gate_decision) does not hash to its stated entry_hash: its
contents were altered after it was written
ok run_numbers: was every run started once, and ended in the ledger, with no unrecorded runs?
runs [1, 2], contiguous, each started once and ended in the ledger
ok plan_versions: is every plan version the ledger records present in the bundle?
2 version(s) — the plan was amended during the participation
warn plan_signatures: was the plan signed by each party, through their own identity provider?
the plan was signed with keys the sandbox holds, not through the
parties' identity providers: the bundle shows that the sandbox signed
it, not who agreed to it
warn report_signature: was the exit report signed by the regulator, through their own identity provider?
report sha256:eb92d315df53… is signed through the development IdP, which
issues a token for anyone: the signature identifies nobody
ok artifact_digests: do the artifacts in every run match the pins of the plan it cites?
2 run(s) match the plan's pins
ok dataset_commitments: was every dataset used committed before the run that used it?
1 committed
warn isolation: is isolation evidence present and does it match the plan's policy?
NO ISOLATION WAS ENFORCED. Every run in this bundle was executed as
ordinary processes on one host. The results describe what the model
answered; they establish nothing about whether it could have reached the
data or the network. This bundle is a development artefact and is not
sandbox evidence.
ok run_logs: do the run logs in the bundle match the digests their attestations carry?
4 logs match their digests
ok harness_statements: did the harness sign what it measured, and does the attestation agree?
2 run(s): the harness signed its measurements and the attestation agrees
ok thresholds: does every stated outcome follow from the numbers reported with it?
recomputed and consistent
warn sample_sizes: were any thresholds passed on samples too small to mean anything?
2 group(s) fell below the plan's minimum and were not scored: run 1
accuracy_by_group mae age_band=18_24 (n=9), run 2 accuracy_by_group mae
age_band=18_24 (n=9)
ok deletion: were keys destroyed after exit?
keys destroyed after exit: ['data/demo-001/lab-heldout-v1']
FAIL completeness: does the ledger end as a participation that has ended does?
the report at seq 25 was generated over bundle sha256:fff8a8b2304d…, but
this bundle, up to the entry before it, is sha256:f47e62f8fd00…: files
were changed after the report
warn timestamps: are the timestamps valid, ordered, and external?
every timestamp was issued by the sandbox operator's own development
authority, not by a third party. The ordering is self-consistent and
anchors nothing: an operator able to rebuild this ledger could reissue
these timestamps with it.
warn tsa_revocation: was the timestamp authority's certificate unrevoked when it stamped?
no RFC 3161 timestamp in this ledger, so no authority certificate whose
revocation could be checked: development timestamps carry none
ok personal_data: does the manifest say what personal data the bundle holds?
as the manifest says, the bundle holds personal data: staff identifiers
(7, in ledger.jsonl, plan.json, plans/); idp id tokens (1, in
ledger.jsonl), and no test-subject data (none of the files the export
writes can carry it)
ok i18n_catalogues: is the catalogue each translated rendering of the report was made with in the bundle, as the ledger records it?
the report was rendered in English only: no catalogue to carry
ok report_renderings: is the exit report rendered in every language the plan names, each rendering named by hash in the authentic report?
the plan names no languages: one report, in English
ok anchor_plan_digest: is every plan in the bundle one whose digest you hold?
2 plan version(s), every signing and every run match the digest(s) you
gave
ok anchor_sandbox_id: is this bundle the participation you were told it is?
manifest, ledger, plans and runs: demo-001
warn anchors: were the trust anchors given from outside the bundle?
the timestamp authority's root, the identity providers' keys, the
network policy digest, the harness image digest, the audience the
parties' IdP logins were for, the ledger head came from the bundle
itself: the checks against them show that the bundle agrees with itself,
not that it is the one you signed. An operator who rebuilt it could have
replaced them all consistently. Pass them from outside, with --anchors
or the --expect-* options.
ok bundle_digest: does the bundle match the digest in its own manifest?
sha256:182a99098581a09e85724c7ecb0cfb1e46f69f66fdd2b0f9352535a83247fd3e
NOT VERIFIED — 2 check(s) failed
Anchors given from outside: plan_digest, sandbox_id, signing_keys
Anchors read from the bundle: tsa_root, idp_keys, policy_digest, harness_digest, audience, ledger_head
What this bundle does NOT establish:
- plan_signatures: the plan was signed with keys the sandbox holds, not
through the parties' identity providers: the bundle shows that the
sandbox signed it, not who agreed to it
- report_signature: report sha256:eb92d315df53… is signed through the
development IdP, which issues a token for anyone: the signature
identifies nobody
- isolation: NO ISOLATION WAS ENFORCED. Every run in this bundle was
executed as ordinary processes on one host. The results describe what
the model answered; they establish nothing about whether it could have
reached the data or the network. This bundle is a development artefact
and is not sandbox evidence.
- sample_sizes: 2 group(s) fell below the plan's minimum and were not
scored: run 1 accuracy_by_group mae age_band=18_24 (n=9), run 2
accuracy_by_group mae age_band=18_24 (n=9)
- timestamps: every timestamp was issued by the sandbox operator's own
development authority, not by a third party. The ordering is
self-consistent and anchors nothing: an operator able to rebuild this
ledger could reissue these timestamps with it.
- tsa_revocation: no RFC 3161 timestamp in this ledger, so no authority
certificate whose revocation could be checked: development timestamps
carry none
- anchors: the timestamp authority's root, the identity providers' keys,
the network policy digest, the harness image digest, the audience the
parties' IdP logins were for, the ledger head came from the bundle
itself: the checks against them show that the bundle agrees with itself,
not that it is the one you signed. An operator who rebuilt it could have
replaced them all consistently. Pass them from outside, with --anchors
or the --expect-* options.Scope a testing component for 2027 you can fund and defend.
sandbox operators and innovation agencies
- Choose the host: your HPC partner or AI Factory.
- Keep your method and test catalogue; Histor is the evidence layer beneath.
- Be first in: the founding-partner offer →
Your staff never see: the test data.
Why now
Sandboxes so far gave advice. The next ones have to test.
Article 572 August 2027
Every Member State must have at least one operational sandbox.
Annex III2 December 2027
High-risk obligations apply; providers will want tested results before then.
Draft implementing actConsulted Dec 2025
Tells authorities to use AI Factories and supervise projects run there.
See for yourself
Three things you can check today
The 3-minute film
One supervised test run on a cluster, silent and captioned.
The read-only console
Click through a supervised run as the authority sees it.
The offline verifier
Run it on the sample bundle, on your own machine, with no network and no account.
Founding partner
One sandbox, first in, shapes the 2027 testing.
Histor is taking one regulatory sandbox as founding partner for its 2027 cohort.
- A free proof of concept at its own HPC partner
- Four to six weeks, one participation on synthetic data, the authority verifying the result itself. No fee, no obligation, and the outputs published.
- Its staff trained
- The host's operators and the authority's verifier seat, trained on the partner's own run.
- Its requirements in the public release
- What the partner needs for its 2027 testing component shapes the public release, so its later tender can ask for functions, not a product.
- Named first in the release notes
- The founding partner is named first, with its host, in the release notes and the documentation.