Security

Tenant isolation fails closed

Isolation is enforced in the database by row-level security, not by a `WHERE` clause somebody has to remember. A query issued without a tenant context does not return the wrong rows — it returns nothing. That distinction is the whole design: a filter that is merely forgotten leaks, while a policy that is absent starves. We take the failure mode that is loud on our side and silent on yours.

Personal data is sealed on the way in

Identifying and clinical fields are encrypted per data subject under a key that exists only for that subject. The ledger stores ciphertext. Nothing downstream — no report, no export, no backup — holds a readable copy that could survive the destruction of the key.

The audit trail is hash-chained

Each audit record commits to the one before it, so editing a row invalidates every row after it. The question "has this log been altered" has an answer that does not depend on trusting us. Valuations are superseded and never overwritten: the mark you were shown last quarter is still the mark you were shown last quarter.

Identity, not shared secrets

Authentication is multi-factor. Authorisation is role-based and evaluated on the server for every request, because a control enforced only in the interface is decoration. Sensitive actions — funding, releasing a lien, moving money — record who, when, from where, and on what evidence.

Every credential is held in a managed key vault and read through a workload identity at runtime. There are no secrets in the source, in the deployment pipelines, or in a configuration file anyone can copy. Administrative access to the database is by identity rather than a shared password.

Reporting a vulnerability

Send it to sales@mindhyve.ai with "security" in the subject and it will be routed to engineering the same day. We will confirm receipt, tell you what we found, and tell you when it is fixed. We do not currently run a paid bounty programme, and we would rather say so than imply one.