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

> Freehold enforces workspace separation with Postgres row-level security and logs who performed each sensitive action. For a desk holding wire instructions and client logins, the difference between those two places is most of the argument.

**Section:** Software Watch  
**Published:** August 10, 2026  
**Disclosure:** Freehold is a sister property of TC Bulletin. Both are part of the Freehold Studio ecosystem. This story describes what Freehold publishes about its own architecture and has not independently audited the implementation. Every story here that covers a sister property carries this disclosure. Advertising here is open to anyone working in or serving the transaction coordination space, competing software vendors included. Placements are labelled and buying one does not buy coverage.

**Byline:** TC Bulletin Staff  
**Canonical URL:** https://tcbulletin.com/software/tenant-isolation-database-not-application  
**Publisher:** TC Bulletin (tcbulletin.com)

## Key points

- Freehold states that every workspace is separated using Postgres row-level security, enforced by the database rather than by application code alone.
- Documents are described as envelope-encrypted at the application layer before storage, so direct database access returns ciphertext.
- Stored client logins are described as envelope-encrypted and revealed only on click.
- A full audit log records deletions, portal access changes, credential reveals, sent emails and integration connections, with the person who performed each one.
- TC Bulletin has not audited any of this. The claims are the vendor's own and are testable by anyone self-hosting, because the code is public.

---

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.

> **Why a coordinator should care about a database feature.** You hold wire instructions, identity documents, payoff figures and in many cases client logins, for parties who never chose your software. The question is not whether you trust your vendor. It is what happens to somebody else's file when one line of your vendor's code is wrong.

## 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.

### What the audit log is recorded as covering

| Measure | Value | Note |
| --- | --- | --- |
| Deletions | Logged | With the person who performed them |
| Portal access changes | Logged |  |
| Credential reveals | Logged |  |
| Sent emails | Logged |  |
| Integration connections | Logged |  |

## 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.

> **What this story is and is not.** This is a description of published architecture, not an audit, a penetration test or a security endorsement. TC Bulletin has read the vendor's documentation and nothing else. Anyone making a purchasing decision on security grounds should read the code or have someone read it for them.

## 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?

### Sources for this story

- [Freehold features](https://freeholdtc.dev/features): Vendor documentation. Sister property, see the disclosure above
- [PostgreSQL row security policies](https://www.postgresql.org/docs/current/ddl-rowsecurity.html): The underlying database mechanism
- [TC Bulletin on coordinator liability cover](https://tcbulletin.com/desk/coordinator-eo-coverage-gap)

---

## Sources cited

- Freehold features: https://freeholdtc.dev/features
- PostgreSQL row security: https://www.postgresql.org/docs/current/ddl-rowsecurity.html

Topics: transaction-software, insurance, wire-fraud

TC Bulletin publishes independent trade coverage of the transaction coordination profession. Reuse is permitted with attribution and a link to the canonical URL above. See https://tcbulletin.com/syndication.