The usual approach to sensitive fields is to encrypt them and then remember to exclude them everywhere — from search, from exports, from AI retrieval, from the next feature somebody writes. BuildWithHQ removes the need to remember: the searchable value simply is not there.
Encryption is a property of the field definition, so it applies everywhere that field is used rather than everywhere someone remembered.
The encrypted value, its nonce, its key identifier, and its algorithm are stored together, and a database constraint makes storing both plaintext and ciphertext impossible.
Each tenant has its own key registry, so key handling is a tenant-scoped concern rather than one shared secret.
Reading the value is a separate, authorized operation. Rendering a page never triggers decryption as a side effect.
This is a small idea with a large consequence.
When a field is encrypted, the plaintext column is null. Nothing is stored there. That means every path that reads plaintext — keyword search, list views, exports, embedding generation for AI retrieval — finds nothing, with no special-case code in any of them.
The alternative, which most systems use, is to store the plaintext and then filter it out of each read path. That works until the eleventh read path, written eighteen months later by someone who did not know the rule existed.
Security that depends on every future developer remembering a rule eventually fails. Security enforced by a database constraint does not.
A reveal is an explicit request, authorized against the same permission function as everything else, and recorded whether it succeeds or fails. Decryption happens in the application tier, per principal, and the page layout can never cause it — a masked placeholder is what the renderer sees.
Because there is no searchable value, encrypted fields never enter embeddings. Keeping sensitive data out of AI retrieval requires no configuration and no vigilance.
Not by its value, and that is deliberate. If a field must be searchable, it should not be encrypted at rest in this way — the two requirements genuinely conflict.
Only a principal with read permission on that record, and every reveal is logged with the outcome, including refusals.
No, because ordinary page rendering never decrypts. Only an explicit reveal does the work.
Create an account, explore the full builder console, and launch your first application on a custom domain. Nothing is charged while your application is still in development.
No credit card required. The console preview, the documentation, and the architecture reference are all readable before you sign up.
Get started free Read the docs