Tenant isolation

Multi-tenant software serves many customers from one application and one database, which is why it is affordable — and why isolation is its first obligation. Tenant isolation means every row of customer data carries the identity of the tenant that owns it, and every query the application runs is scoped to exactly one tenant. Done properly, a bug in business logic can produce wrong answers, but not someone else’s answers.

Why it matters

Cross-tenant leakage is among the most severe failures a SaaS product can have: one customer seeing another’s contacts, invoices or conversations. The defense is architectural, not procedural — isolation enforced in the data layer applies to every feature automatically, whereas isolation implemented per-endpoint is only as strong as the most careless endpoint. When evaluating a vendor, the useful questions are structural: is the tenant column on every table, is scoping enforced centrally, and what separate, harder-gated path exists for the vendor’s own staff access?

How tenant isolation works in Oneop

Isolation is enforced at the data layer on every query. Of Oneop’s 329 database tables, 275 are tenant-scoped and carry a tenant_id column. The other 54 are the operator console’s own tables, global reference data such as tax jurisdictions and languages, and child rows that reach their tenant through a foreign key to a tenant-scoped parent rather than by carrying the column twice. Public signup cannot cross the boundary either: registration hardcodes the new user’s role and refuses any caller-supplied tenant ID.

Sessions are separated by principal, not just by tenant. The tenant app, the internal operator console and the client portal are three distinct session systems with distinct cookies and distinct signing secrets — and production boot fails hard if the secrets are not all different.

The one deliberately cross-tenant context — Oneop’s internal operations plane — is separately gated, disabled unless it is explicitly switched on, and requires mandatory two-factor for every operator. Support impersonation there is time-boxed, idle-limited, revocable mid-session, re-checked on every request, and hard-blocked from billing, credentials, passwords, MFA and destructive actions. Every operator action lands in an append-only audit log with no update or delete route.

AI respects the same boundary: every model call is scoped and metered per tenant, so agents read and act only inside the workspace that invoked them.

Related terms: AI governance. Full control list: Security.