ar.io
Proof without access

Prove what you can't share.

Most AI audit tools work by ingesting your data. Logs ship to a vendor, model weights get wrapped by a monitoring layer, training samples sit in a SaaS dashboard. ar.io anchors cryptographic fingerprints instead. The underlying bytes never leave your perimeter.

Book a demo
See how it works
SHA-256·Digital signatures·Permanent anchor
The verifierAuditor · Regulator · Partner
Sees
  • Cryptographic fingerprint (SHA-256 hash)
  • Digital signature authenticating the commitment
  • Anchored timestamp from permanent storage
Does not see
  • Training data or fine-tuning corpora
  • Model weights or checkpoints
  • Customer prompts or inference inputs
  • Inference outputs
  • Anything else inside your perimeter
01 — What it is

Proof without access, and what it isn't.

A verification model where an auditor or service provider can confirm that a piece of data, a model checkpoint, or an inference output has not been altered, without ever holding a copy of that data. The owner generates cryptographic fingerprints locally, commits them to a tamper-evident record, and later re-derives the fingerprint from the original artefact to prove the match. The verifier sees only the fingerprint and the anchored timestamp, never the underlying bytes.

What it is
  • Integrity proof: the artefact has not been altered since it was committed.
  • Existence-at-time proof: the artefact existed at the anchored timestamp.
  • Self-authenticating: a regulator verifies the chain independently, without trusting ar.io.
  • Built on standard cryptography: SHA-256 hashing, digital signatures, anchored records.
What it isn't
  • Zero-knowledge cryptography (those prove statements about hidden data; this proves integrity).
  • Proof that the data was correct, lawful, or unbiased.
  • Proof that a model's output is right; only that it matches what was committed.
  • A replacement for governance, evaluation, or risk-management programs.
02 — How it works

Four steps. Three primitives any security engineer can verify.

Proof without access combines content-addressed hashing, digital signatures, and tamper-evident anchoring. The flow is roughly the same whether you're committing a training dataset, a model checkpoint, or an inference output.

  1. 01

    Fingerprint

    Generate a cryptographic hash of the artefact (training data, model checkpoint, inference I/O) inside your environment. The hash is deterministic and one-way: same input always produces the same fingerprint, and you cannot reverse the fingerprint into the data.

  2. 02

    Sign

    Sign the fingerprint with your private key. This proves the commitment came from you and not from an attacker who intercepted the hash. Same cryptography that secures TLS, SSH, and code signing.

  3. 03

    Anchor

    Write the signed fingerprint to Arweave through ar.io's gateway network. Every entry is cryptographically linked to those before it and stored across a global network of independent nodes. Altering the record would require rewriting the chained history.

  4. 04

    Verify

    Months or years later, the verifier re-hashes the artefact and compares the result against the anchored fingerprint. A match proves integrity. A mismatch is visible. The verifier learns only that the fingerprint existed at the timestamp and that the current artefact matches.

Building blocks

Each primitive is public and well-studied.

03 — vs. nearby ideas

Proof without access, vs. the cryptographic neighbours.

Several adjacent ideas overlap with proof without access without being the same thing. Here's what each one shows the verifier and when it's the right fit.

Proof without access

This page
Verifier sees
Fingerprint, signature, and anchored timestamp.
Proves
Existence and integrity of an artefact at a point in time.
When to use
Audit trails, model lineage, content provenance. Most enterprise compliance evidence.

Zero-knowledge proofs

Verifier sees
A proof that a statement about hidden data is true.
Proves
A specific predicate (for example, 'this output was produced by a model with these parameters') without revealing the data or the parameters.
When to use
Cases where you need to prove a computation, not just integrity. Computationally heavy and requires specialised circuits.

Confidential computing / TEEs

Verifier sees
Output of a trusted enclave running the workload.
Proves
That code ran inside an attested hardware environment.
When to use
Real-time inference where the verifier needs to trust the runtime, not just the artefact.

Mutable database audit logs

Verifier sees
Whatever the database admin allows.
Proves
That the vendor's database currently shows these entries.
When to use
When you trust the audit vendor and their database. Falls short for self-authenticating evidence.
04 — FAQ

Frequently asked questions.

01Does ar.io see my training data, model weights, or customer prompts?
No. The integration generates fingerprints locally, inside your environment, behind your firewall, or in your VPC. Only the fingerprint, the signature, and metadata you choose to attach are anchored to the tamper-evident record. The underlying data does not transit ar.io's infrastructure.
02What if my data changes? Can I still prove old versions existed?
Yes. Each version produces a distinct fingerprint, and each fingerprint is anchored with its own timestamp. The full version history is preserved. Re-hashing an older copy of the artefact, if you've kept it, will match the older anchored fingerprint.
03Is this zero-knowledge cryptography?
No, and the term matters. A zero-knowledge proof lets you prove a statement about hidden data (for example, “I ran this model and got an output in this range”) without revealing the data or the computation. Proof without access is simpler: it proves integrity and existence, not arbitrary statements. ZKPs are an active research area in AI verification but require specialised circuits and are computationally heavy. Most enterprise audit-trail requirements do not need them.
04What stops someone from faking a fingerprint?
Two things. A cryptographic hash is computationally infeasible to reverse or to collide on for current standard algorithms; there is no known way to produce a different artefact that hashes to the same SHA-256 fingerprint. And because each commitment is signed with the data owner's private key, an attacker would also need to forge the signature. The tamper-evident anchor adds a third layer: changing an existing record on Arweave would require rewriting the network's chained history. No system is provably secure forever, so a robust audit program should plan for hash agility as algorithms are retired (MD5, SHA-1).
05How is this different from putting hashes in a database?
A database is mutable by definition. An administrator with the right credentials can rewrite a row, and unless someone exported a copy beforehand, the change is invisible. A tamper-evident substrate makes any alteration detectable, and a permanent substrate (Arweave, underneath ar.io) makes the original record survivable even if the vendor disappears. Database audit logs are useful; they're just not the same kind of evidence.
06Does this work for closed-source or third-party models?
Partially. You can fingerprint anything you control: the prompts you send, the outputs you receive, the evaluations you run, the wrapper code, and any model weights you host yourself. You cannot fingerprint the internals of a closed model running on someone else's servers. For that you need the model provider to participate, or you rely on techniques like attested inference (TEEs) or input/output binding.
07How does the EU AI Act treat this kind of evidence?
The EU AI Act (Regulation 2024/1689) requires providers of high-risk AI systems to maintain technical documentation, automatic logs, and post-market monitoring records sufficient for conformity assessment. It does not prescribe specific cryptographic methods; it requires the evidence to be reliable, traceable, and available to authorities. Cryptographically anchored audit trails are one defensible way to meet that standard, and they have the advantage of being independently verifiable by an auditor without trusting the AI provider's internal database. The same logic applies to the NIST AI Risk Management Framework measure and manage functions. See the EU AI Act compliance page for the article-by-article requirements.
Get started

Anchor what you can't share.

Fingerprint your training pipeline, model registry, and output stream inside your environment. Only the hash and timestamp leave your perimeter. Regulators verify independently.

Book a demo
See Internal AI Audit