Tenant isolation

In a multi-tenant platform, the question that matters is not "does the query filter by tenant?" but "what happens the one time it doesn't?"

The problem with filtering in application code

The common approach scopes every query in the application:

-- illustrative; the real table and column names are internal
SELECT * FROM <tenant_scoped_table> WHERE <tenant-id-column> = $1 AND ...

This works until it doesn't. It relies on every query, written by every engineer, forever, remembering the clause. The failure mode is silent — a missing WHERE returns more rows, not an error — and the blast radius is cross-tenant data exposure, which is the worst outcome the system can produce.

Code review and helper functions reduce the probability. They do not change the category: the boundary is still a convention that application code is trusted to observe.

Moving the boundary into the database

IntegraHive enforces isolation with PostgreSQL row-level security, bound to a least-privilege runtime role. The policy is evaluated by the database on every query. An application query that forgets its tenant predicate returns the rows that the current tenant context permits — not everything.

This makes the dangerous bug unrepresentable rather than merely unlikely. The application can still have bugs; it cannot have this bug.

That is the design claim. What has been proven about it is a separate question, answered under Current status at the end of this page.

Two supporting decisions carry weight:

A least-privilege runtime role. Row-level security is bypassed by table owners and by superusers. Enforcing it therefore requires that the application connects as a role which is neither — a role holding exactly the rights it needs and no ability to disable the policy protecting it.

Tenant context set per transaction. The policy compares against a context value established for the unit of work, so a pooled connection cannot leak a previous request's tenant into the next one.

The harder problem: proving it

Implementing the control is the easy half. The half that took longer was producing evidence that it works — evidence that survives the process that generated it.

The verification runs as a one-shot job: connect as the runtime role, attempt cross-tenant reads and writes that must fail, attempt in-tenant operations that must succeed, and emit a structured verdict.

The first design passed. It also proved nothing.

The job completed successfully and the platform reported success — but the pod had been garbage-collected before its result envelope could be captured. What remained was an exit status, which says the process ended, not what it concluded. A control that is verified by an unreadable result is not verified.

The redesign binds the verdict to durable evidence from the run that produced it: the result is captured before the executing resource can be reclaimed, and the adjudication step refuses to report a pass unless it can point at evidence from that specific run. Ambiguity is an explicit outcome — a distinct verdict, not a pass — rather than being rounded to success.

That distinction generalises well beyond this system:

A control that works and a control you can demonstrate works are different deliverables. Only the second one survives an audit, an incident review, or a new engineer asking "how do we know?"

The tempting shortcut — inferring the verdict from platform logs — was rejected because it depended on an undocumented log field. A verification whose correctness rests on an implementation detail the vendor never promised is a verification with an expiry date nobody wrote down.

Current status

The control is implemented and the redesigned verification is in place. It has not yet produced a clean end-to-end pass bound to durable evidence from its own run. The honest status is implemented; end-to-end proof in progress — not proven.

Stating that is the whole point. A page that argued for the difference between a control that works and evidence that a control works, and then quietly claimed the evidence, would be committing the exact error it describes.