Integrity and tamper evidence
Every protected write is sealed, chained and checked, so nobody can quietly rewrite the past.
ExploreOne platform for data that has to stay sealed.
Nobody reads it without permission. Nobody changes it without it showing. Anyone can check both.
Three layers, used together or apart
Every deployment starts with integrity: each protected write is sealed and chained, so tampering shows. Where the people running the system must not be able to read the data, add zero-knowledge encryption. Where many people need to work on the same sealed records, add access governance.
Integrity ships today as an SDK for PostgreSQL and MySQL. Zero-knowledge encryption and access governance run in production in a live healthcare messaging deployment, and reach new customers through a guided pilot. All three share one model, so adding a layer later never means starting again.
Explore each part of the platform
Three layers, built on Ghost Tables and backed by independent proof. The engineering detail is available to customers and certification candidates under NDA.
Zero-knowledge encryption
Data is sealed on the user’s side, so your infrastructure stores it without ever being able to read it.
ExploreGhost Tables
Stored data that gives anyone studying it nothing to work with.
ExploreAccess governance
Many people working on the same sealed records, each with exactly the access they were given.
ExploreIndependent proof
Integrity evidence built to be checked outside your organisation.
ExploreDeployment
How the platform runs inside your own systems, and the path from first conversation to production.
ExploreBuilt to stay out of the way
Ghostables lives inside your application and your existing database. There is no separate service to run, no data sent to Ghostables, and no change to how your people work.
- Your queries run unchanged, wrapped by the platform
- Integrity layer on PostgreSQL and MySQL today
- Existing records are sealed in the background
- Protection travels with every backup and replica
// Before: a standard insert
await pool.query(insertPatient, values)
// After: the same insert, now sealed and chained
await ghostables.insert('patients', id, record,
(conn) => conn.query(insertPatient, values))Honest about scope
Ghostables substantially strengthens the technical side of data protection. It is not the whole of it.
What it changes
A stolen or compelled copy of your data is a copy of sealed records. Changes made to stored records outside the protected path are detected. Exposure from a stolen key or device is limited to a narrow recent window.
What it does not replace
Access control, patching, monitoring, staff training and incident response all still matter. A device compromised while its owner is signed in can see what that person sees, and a compromised service can capture data entered while it is compromised.
How an engagement works
The platform is available to integration partners. Every engagement follows the same path.
Scope
We map your sensitive data, your users and your obligations, and agree which layers apply.
Pilot
Your engineers integrate against a real workload, with ours alongside.
Roll out
Existing records are sealed in the background and protected writes go live.
Certify
Once the deployment meets the Standard, it can be certified.
Find out where sealed data fits in your systems
Our engineers will map your sensitive data and show you which protections apply, before you commit to anything.