DEV Community: Latch Vector

Why enforcing tenant boundaries in application code is a ticking time bomb

Latch Vector — Fri, 21 Aug 2026 08:35:03 +0000

Here is how most multi-tenant SaaS applications isolate customer data when they start out:

// Looks safe, until someone forgets it in a new endpoint
const invoices = await db.query(
'SELECT * FROM invoices WHERE company_id = ? AND id = ?',
[req.user.companyId, req.params.id]
);

It works fine for the first year. Then the team grows, junior engineers join, someone builds an internal bulk export feature, or a developer writes a quick direct SQL query during a midnight hotfix.

Eventually, a route ships where someone forgets WHERE company_id = ?. A customer sees another customer’s invoices, and you spend the next 72 hours writing an incident report to your legal team.

Relying exclusively on application code for multi-tenant isolation means your security boundary depends on 100% human diligence across 100% of your codebase, forever.

That is a mathematically guaranteed failure mode over time.

The "Defence in Depth" Tenant Model
When we built Latch Vector, we approached tenant isolation with a simple rule: The innermost security layer must not care whether the application developer remembered the check.

We implemented a 3-layer boundary where every layer operates independently:

Request ---> [ Layer 1: Application Guard ]
↓ (validated)
[ Layer 2: Postgres Row-Level Security (RLS) ]
↓ (enforced)
[ Layer 3: Database Schema & Triggers ]

Here is how those layers actually work behind the scenes.

Layer 1: Fail-Closed Service Guards
Every request carrying an organization ID is checked against the caller's granted scope (SELF or SUBTREE).

If a token carries no scope, it is refused outright rather than trusted. If an endpoint requires an organization context and none is provided, it fails closed immediately before hitting the storage layer.

Layer 2: Postgres Row-Level Security (RLS)
Layer 1 protects the paths that remember to call it. But what about a new repository method added next month? Or an ORM query built dynamically?

This is where the database enforces its own boundary. We run Postgres with Row-Level Security (RLS) on a dedicated, non-superuser application role:

-- Postgres RLS Policy Example
CREATE POLICY tenant_isolation_policy ON invoices
FOR ALL
USING (tenant_id = current_setting('app.current_tenant_id'));

If a developer writes SELECT * FROM invoices without a WHERE clause, the database itself filters the rows based on the session's tenant context. An un-scoped query returns zero rows, not all rows.

Layer 3: Schema Constraints & State Immutability
The deepest layer prevents illegal states from ever being written:

Composite Foreign Keys: Prevent a child record's tenant_id from disagreeing with its parent entity.
Materialized Path Triggers: Automatically derive an organization's position in the customer hierarchy, like Health System to Hospital to Department, so an org tree node cannot be corrupted by an invalid update.
Immutable Audit Trail: The append-only audit log table strictly rejects UPDATE and DELETE operations at the database driver and schema level.

Measuring the Boundary (Not Asserting It)
We do not just assert that tenant boundaries hold on a marketing datasheet.

Our test suite includes an automated 165-check cross-tenant leak matrix. It actively attempts cross-tenant reads, sibling branch traversal, and privilege escalation attacks against real Postgres databases (not emulated mocks) before any build is tagged for release.

How do you enforce tenancy?
If you are building multi-tenant software, where does your security boundary live today? Is it purely in your ORM or application middleware, or are you enforcing it down at the database layer?

We packaged this 3-layer isolation pattern, along with multi-tenant SSO, audit logging, and official SDKs (Node, Python, PHP, Java) into Latch Vector.

You can read the full architecture details in our public docs: Documentation

Curious to hear how other backend engineering teams handle tenant isolation in their stacks!

The most common SSO breach is a config mistake. So we removed the config.

Latch Vector — Thu, 13 Aug 2026 08:01:42 +0000

Here's a bug that has shipped to production in more companies than anyone wants to admit:

const payload = jwt.verify(token, publicKey);
// looks fine. it isn't.

Valid signature. Right issuer. Not expired. And minted for a different application. One your user also has access to. Maybe one that isn't even yours. Nothing in that line checks who the token was for.

That's the aud claim. It's optional in most libraries, off by default in a lot of setups, and the single most common way an SSO integration turns into a lateral-movement path.

We got tired of writing that check in code review comments, so we built an identity platform where it isn't a check you can forget.

What Latch Vector is

Multi-tenant SSO and identity for regulated software. Tokens, organizations and sub-organizations, fine-grained permissions, and immediate notification when access changes, with tenant isolation, encryption at rest and a real audit trail built in rather than assembled by you.

It's built for teams who would have to explain a cross-tenant leak to a regulator.

Four things worth your attention

1. The audience check has no off switch.

const principal = verifier.verifyAuthorizationHeader(req.headers.authorization);
if (!principal.has("invoice.approve")) return res.status(403).end();

No variant of that call skips the audience. A token minted for another application is rejected, always. A machine token is refused where a user token is expected, and the reverse. The pattern is fail-closed: social login with no configured client id gets refused rather than trusted, and missing configuration raises an error instead of quietly allowing something.

2. Tenant isolation at two independent layers. Postgres row-level security through a dedicated non-superuser role, plus an application-layer tenant guard on every org-scoped endpoint. Neither one alone is the security boundary, so a bug in one doesn't become a breach.

Organizations are a materialized-path tree. You can model a health system → hospitals → departments and delegate administration down it with SELF and SUBTREE scopes. We verify the wall with an automated 165-check cross-org leak matrix instead of asserting it in a datasheet.

3. Your app finds out the moment access changes. Role assigned or revoked, permissions edited, account disabled or erased: HMAC-SHA256 signed, replay-protected, delivered at-least-once through a transactional outbox, so the event and the business change commit together or not at all. Editing a role also invalidates the current tokens of everyone holding it, so revoked access doesn't linger until expiry.

if (!verifyWebhook(rawBody, sig, ts, secret)) return res.status(400).end();

4. Migration that doesn't cost your users their passwords. Describe your whole estate in one payload that references records by your own ids. A dry-run reports every bad email, duplicate and broken link before a single row is written, then commit provisions it in one transaction. bcrypt hashes carry over verbatim, so those users keep the password they already have. The import is idempotent, so retries are safe.

Also in the box

TOTP MFA. Refresh-token rotation with reuse detection, where a replayed token gets treated as a compromise signal rather than an ordinary 401. AES-GCM encryption at rest with rotatable keys and a blind index so encrypted emails stay searchable. GDPR erasure that scrubs personal data while keeping internal ids stable. SDKs for Node, Python, PHP and Java/Spring, all enforcing the same defaults.

Live today. Public docs, published SDKs, and a sandbox tenant you can spin up without talking to anyone.

docs.latchvector.com · latchvector.com/services

Hit any of these problems yourself? I'd like to hear how you solved it. Responses are open.

Identity for software that gets audited.