How per-user data isolation prevents cross-tenant access

Beyond encryption, HIIE enforces that you can only ever see and act on your own data. Isolation is built into both the database layer and the cryptography.

One gateway, owner-scoped queries

The data store is Cloudflare D1. A single module is the only place that reads or writes D1 and performs cryptography. Every function there takes the authenticated Clerk user ID and scopes every SQL row to its owner. As a result, cross-tenant access is impossible even if a query had a bug — rows that don't belong to you are never in scope.

Cryptographic backstop

Isolation is reinforced by the encryption design. Each project and folder uses a distinct key derived from a server-only master key, and the bucket id is bound into AES-GCM as additional authenticated data. Decryption fails if the key or bucket doesn't match, so even a misrouted read can't return another tenant's content in readable form.

Scoped deletes

Deleting a project removes all of its encrypted data — the stored items, activity rows, and the project record — and the operation is scoped by owner. You can only delete your own projects.

Credentials are isolated too

Account-level bring-your-own provider keys live in a separate, account-scoped encrypted vault and are never returned to the browser. For integrations, even the shared managed path always passes your user id so calls stay isolated per user (enforced in code, not cryptographically).

The result

Isolation is layered: authenticated identity on every query, owner-scoped rows, and per-bucket keys with bucket binding. A single bug in one layer doesn't expose another tenant's data, because the other layers still hold.