Until now, encrypted data had to be exposed to be used.
Seshat ends that.
Your data stays continuously encrypted, and your systems run exactly as they do today.
The gap
This isn’t something your team got wrong. For twenty years, “encrypt your data” has quietly meant “encrypt it while it’s sitting still.” That was the best anyone could do, so it became the standard; and then it became the assumption.
State 01
At rest
Sitting on disk, or the system is powered down.
Encrypted
State 02
In transit
Moving across the network between systems.
Encrypted
State 03
In use
Being queried, analyzed, or served to an application.
Readable by anyone with access
99%
of a running database’s life is spent in that third state. To process a query, the engine decrypts your data into memory. That is simply how databases work.
In that state, a database administrator, a contractor with valid credentials, or anyone who compromises a privileged account can read all of it in plain text. Nothing looks unusual. No alert fires. The query looks like every other query.
How it works
That is the part people assume is impossible, because previously, it was. The shift is simple to describe: instead of opening your data so software can use it, the work moves inside the encryption and happens there.
Your data stays where it is, encrypted
In the databases and systems you run today. No migration, no rip and replace, and your existing applications keep working.
The work happens inside
Searches, queries, analytics, and AI retrieval all execute against encrypted data. There is no readable copy sitting in memory while they run.
You decide what comes out
Results cross the boundary only in the form you allow, to the people you allow. Change your mind later and you can revoke it, even after data has been shared.
Watch the work move inside the encryption.
No product screens. No jargon. Just the idea itself, and why nothing readable ever leaves.
What that changes
An attacker who gets in finds nothing worth taking
Records, configuration, and logs are all encrypted, so there is nothing readable to pivot on and nothing usable to steal.
Zero Trust that finally reaches the data layer
Most programs secure the network and verify identity, then stop; Donoma enforces it where the loss actually happens, so even a verified user cannot read what they were never entitled to see.
Your AI provider never sees your content
Retrieval runs on encrypted material, so the data you feed a model is never exposed to whoever operates it.
Data sovereignty, wherever your data travels
Residency and jurisdiction stop being an architecture problem when the data is unreadable to every system it passes through.
Adoption
Protection that forces you to rebuild is not protection you will deploy.
Fast performance
Day to day, your systems respond the way they always have.
Highly scalable
Software-based and horizontally scalable. It keeps pace as your workloads grow.
No special hardware
Standard CPUs. No enclave chips, no GPUs, no infrastructure project.
Securing AI data usage
These projects are going live either way. The exposure they carry is the part nobody put in the business case.
So today your AI runs on the safe half, and the answers it gives back are exactly as limited as the data behind them.
Same question, same AI. Seshat turns protected data into answers instead of exposure.
Questions travel out. Answers travel back. Your data never makes the trip. Seshat handles the key exchanges between the two so nothing has to be managed by hand, and the hybrid boundary lets you set security terms for each destination individually, so anything you choose to share beyond your data estate leaves on conditions you set.
How it compares
You have probably already looked at several of these. The first three columns are where your data stays protected. The last four are what you keep while it is. Until now, no approach has managed both sides of the grid at once.
yespartialnonot applicable
Encryption at rest is the one most people believe they already have covered. It is not marked for transport because it decrypts the data before anything leaves the database, so what travels is readable data inside an encrypted tunnel rather than encrypted data. Terminate that tunnel at a load balancer or a proxy and the values are in the clear.
Homomorphic encryption is the only other approach that covers all three states. It runs orders of magnitude slower than working on ordinary data, needs specialized hardware to be even tolerable, and requires rewriting applications into a specialized programming model.
Key industries
Balances, transaction history, and customer identity stay protected through the queries that touch them most. Institutions can hunt fraud together across organizational lines without ever showing each other a customer record.
Clinical work needs big datasets and privacy rules make gathering them dangerous, which is why so much healthcare AI runs on incomplete data. Records stay protected while they are analyzed, and hospitals can study shared data without pooling it.
Zero Trust mandates ask for control built into the architecture, not written into policy. Most programs cover the network and the login and stop there. Seshat closes the layer where the data actually lives, including across agency lines.
Carriers hold health, financial, and personal-risk data together, alongside underwriting models that are competitive property. Both stay protected. For everyone else, legacy systems gain protection they were never built for, without the rewrite.
Frequently asked questions
No. Your applications connect the way they always have, because Seshat works at the data layer rather than inside your code.
That holds across everything it protects. The systems querying your records keep querying them. The tools searching your files and archives keep searching them. The AI pipelines retrieving from your content keep retrieving. What changes is that none of it has to be decrypted first.
Approaches that live inside the database work the other way around: they require you to rewrite the applications that touch protected data, and then they take away functions those applications depended on.
Seshat protects structured records, unstructured content, and the AI pipelines built on top of both.
AI and retrieval. Your RAG pipelines run encrypted end to end. The embeddings stay encrypted, the retrieval stays encrypted, and the model provider never receives readable content.
Unstructured content. Files and archives encrypted at rest today are usually searchable only by filename or tag, with the content itself locked away. Seshat makes the content itself searchable, which turns a dormant archive into knowledge you can use.
Structured records. Queries, analytics, and computation run on continuously encrypted data with everything intact: joins, ranges, totals, and text search.
What leaves. At the boundary you control what information crosses and in what form.
Secure enclaves protect a different layer than Seshat does. An enclave wraps your application in protected hardware, but your database sits outside it and still hands back readable data. Enclaves also need specific processors and are limited by how much memory they hold. We protect the data itself, straight through the query, on standard hardware. The two are complementary rather than competing.
No. Seshat is a platform, not an implementation of fully homomorphic encryption, and you were right about the speed. Fully homomorphic approaches run orders of magnitude slower than working on ordinary data, need specialized hardware to be even tolerable, and require rewriting applications into a specialized model to use at all. That is a research program, not a deployment. Seshat is a platform rather than an FHE implementation; it runs on standard CPUs with minimal application changes, and everyday workloads run at speeds you will not notice.
Seshat changes what sharing means. Conventionally, letting another party use your data means decrypting it, copying it, and trusting them to protect it on their side. Every hand-off creates another place it sits readable, and you lose control the moment it leaves.
With Seshat you share encrypted data the other party can query and compute on without it ever being decrypted. You decide which data may be shared, which questions may be asked of it, and what each recipient is allowed to see. You can narrow or withdraw that access at any time, after the data is already in their hands.
Each party runs its own environment and holds its own keys, so there is no shared infrastructure and no shared trust dependency between you. Both sides collaborate without either surrendering custody. And it is not only the data that stays protected: an observer cannot readily tell what data exists, what is queried most, or how any of it relates.
It can, and Seshat closes that gap. Your embeddings stay continuously encrypted along with everything else, because Seshat treats the index as data rather than as metadata sitting safely beside it.
The exposure is real and worth understanding. An embedding works precisely because it preserves the patterning of the source material: proximity, relationship, and meaning. That patterning is not a side effect you can scrub out, because removing it is what makes the index stop working. A vector store is the shape of your data in another form, usually held with far less protection than the database it came from, and research has repeatedly shown that original text can be reconstructed from it.
Partly true, and worth being precise about. Recent database releases added post-quantum algorithms for network connections and key management, which genuinely protects data at rest and in transit. It does not change what happens during processing, where data is decrypted in order to be used. Quantum-safe key management does not protect data sitting in the clear. If your data has to stay confidential for years or decades, that is exactly the state those announcements do not cover.
The next step
A solution briefing is a conversation about your systems and what continuous encryption makes possible in them. You talk, we listen, and the useful answers come from there.
Works with the systems you already run, on the hardware you already own.
