All writing Engineering

Tenancy as law

Fibric EngineeringAugust 5, 20255 min read

The reference contract requires reseller_id and tenant_id on governed envelopes and rows. In the live BearScope data plane, row-level security and tenant-scoped application checks provide defense in depth. This is a control boundary to test, not a claim that cross-tenant access is mathematically impossible.

Current scopeVerified BearScope paths plus a broader reference contract

Rows of a ledger separated by hard ruled lines, each row stamped with its own tenant key

Multi-tenant isolation has a long history of being implemented as a habit. The application remembers to add a WHERE clause. The ORM scopes the query, usually. The reviewer catches the endpoint that forgot, usually. Under that regime, isolation is the sum of every developer’s discipline on every code path ever written, and the failure mode is silent: the query runs fine, returns rows, and passes tests. The rows just belong to someone else.

Fibric runs operators that read live commerce data, building telemetry, and customer records, and then act on them. For a platform like that, “usually” is not a security posture. So we made tenancy a property of the substrate instead of a convention of the code. We call the result tenancy as law: not a rule the application follows, but a physics the application lives inside.

Two keys, everywhere, always

The law has exactly two clauses, and they ride on everything.

reseller_id
The partner boundary. Fibric is white-labeled; a reseller operates a slice of the platform for their own customers. This key walls one reseller’s world off from every other’s.
tenant_id
The customer boundary. Within a reseller, each end customer is a tenant. This key is the line one business can never see across, no matter what the query asks for.

Both keys are required fields in the reference EventEnvelope. Governed ingestion should reject an envelope whose scope cannot be established. Current BearScope tables and BFF routes must be verified individually; this article does not assert that every future row or external store is covered.

Enforced below the application

Stamping data is necessary but not sufficient. In governed BearScope storage paths, row-level security can enforce tenant context below application queries, while BFF checks provide another layer. Policy coverage, privileged roles, migrations, and operational access still require testing and review.

This can reduce the blast radius of a missing application filter when row-level policy is active and the connection is not privileged. It does not eliminate misconfiguration, policy bugs, administrative bypass, or data copied outside the governed store.

A security property you have to remember is a security property you will eventually forget. Isolation has to be something the code cannot opt out of.

Why it must extend to actions

Isolation must extend to action credentials, policy lookup, lock keys, idempotency keys, and records. The reference executor rejects actions whose tenant scope cannot be established. A deployment must also verify that connector credentials and downstream resources cannot cross that boundary.

Governed execution records should inherit the same scope and support tenant-limited review. Their trustworthiness depends on verified policy coverage, credentials, retention, and operational controls; it is not free.

The compounding dividend

Structural tenancy controls can make onboarding more repeatable, but each tenant still needs correctly scoped credentials, policies, data mappings, and acceptance tests. Public third-party connector publishing is not open, and no connector should be assumed safe merely because it follows a manifest shape.

Get started → Read the security posture

Keep reading: One envelope · Fail closed