Engineering

Per-tenant encryption: privacy by architecture

A privacy policy is a promise, and promises are only as good as the incentives behind them. We would rather not ask you to trust a promise. Every Ekarche product reads its runtime configuration from a per-tenant encrypted store, so where your data lives and how it flows is enforced by structure — not by a paragraph on a settings page.

A notice is not an enforcement

Most software expresses its privacy stance as text. A policy page, a toggle, a checkbox at signup — statements about what the company intends to do with your data. The trouble is that a statement and the code are two different things, and only one of them actually runs. When the incentive to break the promise grows large enough, the text is the first thing to quietly change, and you find out later, if at all.

We think privacy should be a property of the architecture, not a line in a document. If the structure of the system makes a data flow impossible, no policy is needed to forbid it — and no change of heart at the company can enable it. The question worth asking of any product is not what it promises about your data, but what it is built to be capable of doing with it.

Where the configuration lives

In every Ekarche product, each customer's runtime configuration sits in its own encrypted store — per tenant for the business products, per household for Memoria. That store holds the integrations, the model providers, the retention rules, the data flows. Because the configuration is per customer and encrypted, one customer's settings and data are isolated from another's by where they live, not by a filter in application code that could be bypassed by a bug.

This has a practical consequence: a customer genuinely controls their own integrations and flows, because those decisions are theirs to hold and not ours to override centrally. It also imposes a design rule on us. If a proposed feature cannot be expressed as per-customer configuration, it goes back to design before any code is written — the substrate is not something new surfaces are allowed to route around.

The substrate under the whole family

This same encrypted-per-customer substrate runs beneath Docusift, Memoria, and Lekha alike. It is the reason three products in three very different markets can make the same claim without exception — your data is yours, encrypted, exportable, never the product, never resold — because the claim rests on a shared structure rather than on three separate good intentions.

That is the deeper bet these products exist to prove: that a profitable software business does not need to exploit the people who use it. Read the argument in full in the case against selling your data, and if you are building something that needs this kind of isolation, it is the default we bring to custom work too.

Questions

People also ask

    What does per-tenant encryption mean?

    Each customer's runtime configuration and data live in their own encrypted store — per household for Memoria — so customers are isolated by where their data lives, not by a filter in shared application code that a bug could bypass.

    How is this different from a privacy policy?

    A policy is a statement of intent that can quietly change. Putting configuration and data flows in a per-customer encrypted store makes certain flows structurally impossible, so privacy is enforced by architecture rather than by a promise.