Unreadable
Encryption happens before upload. Nobody can read your data, including us. So when someone asks who else can read this, the answer is an architecture instead of a promise: not your providers, not us.
Sovereign data infrastructure
Your data should be nowhere.
Nowhere readable, and nowhere new: your data stays in the cloud services of your choice, but you take back sovereignty over it.
The problem
Accountability stays local. Access does not.
Cloud storage as it exists today cannot establish who is able to read the data it holds. Providers encrypt files with keys they keep on their own side, and their systems decrypt on demand: for any employee with the right access, for any authority that compels it. The lock is real. It belongs to the operator, and so does the record of who opened it.
The order does not have to come from the regulator that governs the data. A provider headquartered abroad answers to its own law wherever its servers sit, and disclosure comes afterwards, if at all. The notification, the fine and the letter to affected customers stay with the organisation that collected the data, whoever was holding the bytes.
Every assessment ends the same way: describing a control that sits with someone else.
Read why encrypted at rest does not mean private.
The solution
Keep every provider. Change what they can hand over.
DataPrism is an overlay on existing object storage. Files are encrypted client side before they leave the perimeter, split into fragments, and dispersed across independent instances and providers. No provider holds the key, so a request served on any one of them produces fragments nobody can open, and the number of separate addresses a request would have to reach becomes a stated figure rather than an assumption.
A sealed index of the file is anchored on a public register, constant in size whatever the file: no content and nothing readable ever goes there, and a reviewer can fetch the record directly. There is no platform to migrate to: same providers, same regions, same invoices. The data is rewritten through the pipeline, into accounts already yours.
Every scale
One document or an entire estate. Same properties.
Adoption starts where it is worth starting: on everything written from now on, or on an existing perimeter brought through the pipeline once. Nothing has to be re-architected as the scope widens, and one decisive document behaves exactly like millions of records.
Adoption does not require a programme, a budget cycle and a steering committee before anything improves: the most exposed perimeter is covered first, demonstrated, and extended from there. And where pipelines must collect data without being able to read it, the same infrastructure can be designed for blind ingestion: collection without exposure.
Three properties
Unreadable. Unstoppable. Provable.
Three properties you inherit from the architecture, so nobody has to be trusted to uphold them.
Unstoppable
Losing a provider to an outage, a price move or a refusal to serve you stops being a scenario you have to plan around: every file is fragmented and dispersed across independent providers, with built-in redundancy.
Provable
Show a third party that a file exists and has not changed, without opening it and without anyone vouching for you: integrity is anchored in a public ledger as a constant-size fingerprint, whatever the file size.
Already encrypting?
Encryption solves the first problem. Not the ones behind it.
Encrypting before upload stops the provider from reading the data. That is the hard part, it is worth doing, and it is where this pipeline starts too. It is also the point where most architectures stop, which leaves three exposures standing.
-
01
A complete copy still sits at one address.
Whatever reaches that address reaches all of it, in a single operation. Encrypted data taken today can be kept indefinitely, and cryptography that holds now is not cryptography that holds forever. Collection at scale runs on exactly that premise: take the whole thing, keep it, read it later.
-
02
Encryption is not availability.
A suspended account, an outage, a change of terms or a ransom takes the data with it, keys or no keys. The party holding every byte is also the party that can stop returning it.
-
03
Key custody cannot be demonstrated.
It is a statement about an internal configuration, and the evidence for it is the operator's own word. Nothing in it can be checked by the person who has to sign off.
Dispersal across independent providers changes how many separate addresses an operation has to reach, redundancy absorbs the loss of one of them, and an anchored fingerprint is checkable by whoever is asking. Encryption stays the first step. It stops being the only one.
Why now
The question reaches you from your customers before your regulator.
Enterprise buyers now write sovereignty into procurement, and the answer they want is not a promise about who holds the bytes. Questionnaires, audits, transfer impact assessments: they all ask the same thing in different words, and most of the hours go into restating what you cannot demonstrate. Penalties have moved from theory to practice, and the liability stays yours whoever was holding the bytes. The same regulation names the way out: when the exposed data is unintelligible, a breach stops being a letter to every customer you have. Sovereign data infrastructure is the answer mandates are converging on, and what is missing is an architecture that produces it on the clouds you already run.
€485M
already handed down, for reaching EU data from outside the EU. Six months to fix it, or the transfers stop. Where the servers sat was not the question
Art. 34
no duty to tell every person affected, when the exposed data was unintelligible. The report to the regulator still stands
Use cases
Three ways it lands on your desk. One thing to fix.
Different obligations, different teams, different perimeters. In every one of them the work you stop doing is the same: arguing that your data is protected, instead of showing it.
Use case 01
A demand served on your provider returns encrypted fragments.
For teams whose obligations and whose infrastructure sit on opposite sides of a border.
Cross-border data transfer compliance
Use case 02
Store user files no provider can open.
Files your users upload, encrypted inside your process before they leave it, unreadable by every provider that stores them.
Encrypt user data before upload
Use case 03
Lose a provider. Keep the file.
Cut one off and the file still comes back. Demonstrable in a call, not a clause in a contract.
Data sovereignty without changing provider
Developers
Ship sovereign storage by architecture. Without writing a line of cryptography.
Install the SDK, point it at the providers you already pay for, ship: nothing above or below it has to change.
import { readFile } from "node:fs/promises";
import { DataPrismKey, DEFAULT_ENCRYPTION } from "@dataprism/sdk/crypto";
import { CloudStandard } from "@dataprism/sdk/standard";
import { FilePipeline } from "@dataprism/sdk/files";
// Client, providers, project and key secret, one config file in your project:
// docs.dataprism.co/sdk/client
import { client, providers, project, secret } from "./dataprism";
// Create a project: an encrypted namespace you control
const key = DataPrismKey.fromSecret(secret, DEFAULT_ENCRYPTION);
const standard = new CloudStandard(key);
const { cloudId } = await client.prism(standard).create(project);
// Upload: encrypted on this machine, dispersed with redundancy,
// integrity anchored on a public registry
const bytes = await readFile("contract.pdf");
const pipeline = new FilePipeline({ standard, execution: client.execution, cloudId, providers });
await pipeline.upload("contract.pdf", bytes, {
chunkSize: 65_536,
dataShards: 7,
parityShards: 3,
});Proven, not promised
Let your reviewers check it, from day one.
Encrypted, fragmented, dispersed: none of it asks for your trust, and none of it asks for ours. The reliability models below show what the architecture guarantees, and the registry that enforces it is public, so a reviewer can go through it without a call. The difference from every provider relied on so far: this time, the keys and the whole process stay on one side, and it is yours.
-
Research paper
The design end to end, with formal guarantees and reliability models your own team can challenge.
-
Verifiable contracts
The registry is public and documented, down to how each record is read.
Built on a verifiable security architecture
Client-side encryption
What leaves your side is already unreadable, wherever it lands.
No new vendor lock-in
Your providers stay yours, stay replaceable, and stay in contract.
One SDK to integrate
One TypeScript SDK, no cryptography for your team to get right.
Open by design
Public docs, verifiable code, research still to come.
Get started
Have the answer ready before the next review.
Bring sovereign, unreadable, unstoppable and provable storage to the buckets you already have, without a single provider to change. We will map it onto your architecture with you.
30 minutes. Your system or your questionnaire, no slides.