End-to-End Encryption
Think about how Signal or WhatsApp works. You are in a group. Everyone in the group can read the messages. The service that relays the messages cannot. Removing someone from the group means they cannot read future messages. The encryption is invisible — you just type and read.
Legra applies that same model to knowledge graphs.
Traditional Encryption
- Server sees all data in plaintext
- Database operator can read everything
- Compromised server exposes all data
- Access revocation requires manual key rotation
Legra Encryption
- Encrypted before it leaves your machine
- Servers see only encrypted blocks
- Workspace keys control all access
- Removing a member revokes access automatically
What you could not do before
Most graph databases encrypt data in transit (TLS) and optionally at rest (disk encryption). But the server itself sees everything in plaintext. Every query, every triple, every result passes through the server unencrypted. That means:
- The database operator can read all your data.
- A compromised server exposes everything.
- Cloud providers and hosting partners have technical access to your knowledge.
- Sharing data across organizations requires trusting every intermediary in the chain.
Teams work around this with network segmentation, VPNs, and contractual agreements. These reduce risk, but they do not eliminate it. The server still sees plaintext.
What Legra enables
Encryption before storage, before transit, before everything. Data is encrypted on your machine before it is stored, before it is shared, and before it leaves your node. The servers, peers, and infrastructure that store and relay your data see only encrypted blocks. They cannot read them.
Workspaces as encrypted groups. A workspace is not a database with encryption turned on. It is an encrypted group — like a Signal group chat for knowledge graphs. The shared key is what makes data readable. If you have the key, you are a member. If you do not, the data is opaque.
Transparent to applications. Your SPARQL, Cypher, and GQL queries work exactly as they would without encryption. You do not need encryption libraries, key management in your application code, or special client drivers. The Legra node handles everything internally.
Automatic access revocation. When someone is removed from a workspace, new keys are generated. The removed person cannot read any data created after their removal. This happens automatically — no manual key distribution, no re-encryption of old data.
Protection against every intermediary. Storage providers, network operators, cloud platforms, Legra relay nodes — none of them can read your data. The only entities that can are the members of your workspace.
Provable least knowledge. Each Legra role receives only what it needs. A Host can decrypt only the workspaces it has been explicitly trusted to serve. A Gateway routes requests without owning workspace state. A Custodian stores and proves the durability of encrypted blocks without receiving the workspace key or understanding the RDF, document, audio, video, or other content inside them. A Worker receives only the inputs and authority for one bounded job. Encryption is reinforced by process and protocol boundaries.
Residency is more than a pin on a map
Legra distinguishes three different questions:
| Residency question | Meaning |
|---|---|
| Physical | Where is an encrypted block physically stored? |
| Reconstruction | Where can the encrypted logical value be assembled? |
| Semantic | Where do the ciphertext and authority to recover plaintext coexist? |
An unintelligible encrypted block on foreign storage is not technically equivalent to a readable database hosted there. The Custodian cannot decide what the block contains or which residency rule applies. It publishes factual location and assurance information; the workspace placement policy selects suitable Custodians.
Organizations can still require every physical copy to stay within a named region when their law, contract, or regulator demands it. Other policies can keep plaintext-capable Hosts and workspace keys inside the region while using global Custodians for opaque ciphertext. Legra exposes the distinction rather than silently deciding that encryption cancels every cross-border-transfer rule.
A concrete scenario
A pharmaceutical company collaborates with three contract research organizations on a shared clinical data graph. Each party needs access to the shared workspace. The cloud infrastructure that hosts the relay nodes does not. A departing CRO loses access to future data automatically when their membership is revoked.
The conversation shifts from “do we trust this cloud provider?” to “who should be in this workspace?” — because the cloud provider literally cannot see the data regardless.
What makes this different
In most databases, encryption is a layer you add around an otherwise unencrypted system. The database engine operates on plaintext. Legra inverts this: encryption is the foundation, not a wrapper. The identifiers that track your data are derived from the encrypted form — even the identifiers reveal nothing about the content.
This is not encryption at rest. This is not encryption in transit. This is encryption as the default state of all data, at all times, in all locations. Plaintext exists only in memory, on the node that holds the key, for the duration of a query.
Your data is a sovereign asset. Encryption is what makes it sovereign.
Next steps
See the Workspaces guide for operational details on creating and managing encrypted workspaces. Related features: Branching and Merge Workflows, Peer-to-Peer Distribution, and Vector Search for Graph Workloads.