Histor trust centreStatusRequest documents

Trust centre

Histor runs tests of AI models for EU regulatory sandboxes and leaves evidence a regulator can verify without trusting us. Here is our compliance position, the controls we run, who processes data for us, and the documents behind them. Histor is in development: runs so far use synthetic and public data only, and where something is not yet true, this page says so.

Reviewed 2026-10-11
All systems operationalstatus.historlabs.eu

Compliance

Where Histor stands against the frameworks buyers ask about. Nothing here is certified; the status says exactly what holds.

FrameworkStatusWhat that means
EU AI Act, regulatory sandboxes (Art. 57 to 59)Built forHistor's evidence formats and verifier exist to record and check sandbox tests. There is no certification for this; the claim is what the public verifier does.
GDPRSynthetic data onlyRuns so far use synthetic and public test data, so no data about test subjects is processed. The control plane does hold participants' staff data (names, work email, sign-in ids). A DPIA and a lawful basis come before any real data.
ISO/IEC 27001:2022Mapped, not certifiedOur controls are mapped to Annex A in the security pack (on request). No certification body has reviewed the mapping, and Histor holds no certificate.
SOC 2Not heldNo SOC 2 report, Type I or II.
ISO/IEC 42001Not heldNo AI management system certification.
eIDASNot qualifiedTimestamps come from FreeTSA, which is not a qualified trust service provider. Plan signatures are not qualified electronic signatures.
Cyber Resilience ActUnder reviewThe open-source release under EUPL-1.2 is likely outside the CRA; a supported commercial distribution would likely be in scope. Needs legal confirmation.
Open sourcePublishedThe verifier and the evidence formats are public under EUPL-1.2. The engine follows with the first pilot.

Controls

What the system does, by area, and how to check it. "Engine code, on request" means the source is not public yet.

Evidence integrity

  • Every action in a participation, allowed or refused, is written to the ledger before it takes effect, each entry carrying the hash of the one before

    In place

    CheckThe verifier recomputes the chain; the five altered bundles in examples/tampered must fail

  • The ledger database refuses UPDATE, DELETE and TRUNCATE on entries, even for its owner; the console may only read and append

    In place

    CheckTriggers and grants in the engine, published with the first pilot

  • Entries are timestamped by an external RFC 3161 authority (FreeTSA)

    In place

    Checkdocs/verifier.md: check timestamps against a root you fetch yourself

  • histor verify checks a bundle offline, with no network, no test data and no trust in the operator

    In place

    CheckRun it on the sample participation with --network none

Data protection

  • Model weights are encrypted by the provider and decrypted only in the compute node's memory, for one job

    In place

    CheckRuns record the weights' digest; the provider keeps the encrypted copy in their own registry

  • Keys are destroyed at the end of a participation and the destruction is a signed ledger entry the verifier requires

    In place

    CheckThe keys_destroyed check in docs/verifier.md

  • The model receives the test input only: labels, ages, file names and item ids never reach it, and it has no network access

    In place

    Checkdocs/threat-model.md; each run records how isolation was enforced

  • Registry pull tokens are kept in a key store (OpenBao); the ledger records only a reference to them

    In place

    CheckEngine code, on request

  • Key release tied to a hardware measurement (confidential computing)

    Planned

    CheckToday release depends on software we operate; see What we do not claim

Identity and access

  • Each party signs in through an identity provider the plan trusts for its role (in the development setup: Keycloak for the authority, a Google sign-in we configured for the provider); a person acts only if the signed plan names them

    In place

    Checkdocs/threat-model.md

  • The authority's sign-in (Keycloak) requires a one-time code at every login, including the fresh login that signs a plan; repeated failures lock the account

    In place

    CheckKeycloak realm settings; engine runbook, on request

  • Sessions end after 30 minutes idle and 8 hours at most

    In place

    CheckEngine code, on request

  • Administrative consoles are not public; Cloudflare Access admits named administrators only

    In place

    Checkid.historlabs.eu/admin asks for Cloudflare Access

  • Qualified electronic signatures for plans

    Planned

    CheckNot built

Infrastructure

  • All public traffic is served over TLS through Cloudflare

    In place

    CheckAny *.historlabs.eu address

  • The ledger database accepts connections only from the control-plane server, over TLS verified against its CA

    In place

    CheckEngine runbook, on request

  • The console runs in a read-only container with no Linux capabilities

    In place

    CheckEngine runbook, on request

  • Every component is checked each minute from the server and from outside, with a public status page and email alerts

    In place

    Checkstatus.historlabs.eu

  • Point-in-time recovery for the ledger database

    Partial

    CheckThe development database is on a free tier without it; the production design uses hourly backups

Supply chain

  • Releases of the verifier are signed with Sigstore keyless signing by the repository's own release workflow

    In place

    Checkcosign verify-blob with the identity https://github.com/historlabs/histor/.github/workflows/release.yml@refs/tags/v…, files from the latest release

  • Dependencies are locked with hashes; images and model artifacts are pinned by digest in the signed plan

    In place

    Checkpyproject.toml; the plan in the sample participation

  • Signed engine images with SBOMs and build provenance

    Planned

    CheckThe workflow exists; no engine release is published yet

Vulnerability management

  • A published disclosure policy with response targets

    In place

    CheckSECURITY.md

  • Independent penetration test

    Not done

    CheckNone so far

What we do not claim

Sub-processors

Every third party that hosts, carries or processes data for the Histor service. Test data and model weights pass through no service that is not on this list.

EntityPurposeLocationData processed
Oracle CloudHosts the control plane: console, authority sign-in, key store, run dispatcherAmsterdam, NLPlans, signatures, participants' staff data, keys and pull tokens, run results
Aiven (on DigitalOcean)Managed PostgreSQL for the ledgerAmsterdam, NLThe hash-chained ledger, including participants' staff data
CloudflareDNS, TLS, tunnel to the control plane, access control, status pageWorldwide edgeAll traffic to *.historlabs.eu; TLS ends at Cloudflare, so it can read traffic in transit
Barcelona Supercomputing Center (EuroHPC)Runs the tests on MareNostrum 5Barcelona, ESModel image, encrypted weights, test data; weights decrypted only in node memory
RunpodStreams model images and encrypted weights from the registry to MareNostrum 5Romania, Czech Republic, IcelandImage and encrypted weights in transit; nothing written to disk
GitHubContainer registry for model packages in the current pilot (a provider may use its own registry instead); source codeUnited StatesModel image and encrypted weights; source
Google (Workspace and Cloud)Email, including security reports and document requests; the provider's sign-in in the development setupWorldwideEmail with participants' names and addresses; the provider's sign-in identity

Documents

Public documents link to the open repository. The rest are sent on request by email.

FAQ

Can Histor see our test data or model?

The model's weights stay encrypted with the provider's key until they are in a compute node's memory. Test data is sealed and decrypted only inside the run; in the current pilot it is synthetic. We operate the software that releases keys, so we state this as a limit rather than a guarantee: see What we do not claim.

Do we have to trust Histor's report?

No. The evidence bundle can be checked with the public verifier, offline, against trust anchors you obtain yourself. If anything was altered, it fails.

Does Histor train models on our data?

No. Histor does not train models. It runs the tests both parties signed and records the result.

Is MareNostrum 5 contractually bound to confidentiality?

Not yet. BSC has signed no undertaking. Until one is signed, runs there use synthetic and public data only.

Do you have SOC 2 or ISO 27001?

No. Our controls are mapped to ISO/IEC 27001 Annex A, and the mapping is available on request. Nothing is certified.

Where is data stored?

The control plane and ledger are in Amsterdam, tests run in Barcelona. The sub-processor list gives every location.

How do I report a vulnerability?

Email security@historlabs.eu or use GitHub's private reporting on historlabs/histor. We acknowledge within 5 working days.

Updates

Found a security issue? Email security@historlabs.eu. We acknowledge within 5 working days.

Report on GitHub