Tenant isolation belongs in the database, not in the application code

Almost every platform in this category says your data is secure, and almost none of them says where the separation is enforced. It is an unglamorous distinction and it is the one that decides what a bug costs you.

Two places to put the wall

In a shared system, something has to guarantee that one workspace cannot read another's files. That guarantee can live in the application, where every query carries a filter the developers remembered to write, or it can live in the database, where the engine refuses to return rows that do not belong to the caller regardless of what the query asked for.

The practical difference shows up on the bad day. Application-layer separation fails open: one missing clause in one query, one endpoint that forgot the check, and the data crosses. Database-enforced separation fails closed, because the rule is not restated in every query. It is a property of the table.

Freehold's published description is specific about which of the two it uses. Its material states that every workspace is walled off with Postgres row-level security, enforced by the database itself and not just application code.

What sits on top of it

Two further claims in the same material are worth separating from the marketing register they arrive in, because both are checkable statements about where plaintext exists.

• Documents are described as envelope-encrypted at the application layer before they are stored, so that direct access to the database yields ciphertext rather than files.
• Saved client logins are described as living in a credential vault, envelope-encrypted and revealed only on click rather than held in plaintext.

The second is the one coordinators should read twice. Storing portal logins for clients is ordinary practice on a busy desk and it is the single worst thing on most systems, because it is frequently kept in a note, a spreadsheet or a password field that was never designed to hold somebody else's credentials.

The audit log is the part that pays for itself

Freehold's material describes a full audit log covering deletions, portal access changes, credential reveals, sent emails and integration connections, each recorded with who did it.

That is a security feature, and it is also the answer to a question this publication has already covered from the other direction. Specialist brokers describe the coordinator claim profile as missed deadlines, missing signatures, the wrong version of a document and misdirected files. Every one of those is an argument about what happened and when, and every one of them is easier to survive when the system can say so without relying on anyone's memory.

The part that makes the claim testable

Security claims are usually unfalsifiable from outside. A vendor asserts an architecture, and a customer either believes it or does not, because there is nothing to inspect.

Freehold is source-available under the Elastic License 2.0 and self-hosting is free for an organisation's own use, which changes the standing of every claim above from an assertion into something a sufficiently motivated brokerage or IT provider can go and check. TC Bulletin has not done that. The point is that it can be done, which is not true of most of this category.

Questions worth asking any vendor

1. Is workspace separation enforced by the database, or by filters in application queries?
2. Where does plaintext exist, and who or what can read it?
3. Are stored client credentials encrypted, and is a reveal recorded?
4. Does the audit log record who performed an action, or only that it happened?
5. Can I obtain the log, and my data, without asking permission?