Tenant isolation at the query layer

Inspection data is a map of where a plant is weakest. It records which vessels are approaching minimum thickness, which welds carry indications, which lines have an active corrosion mechanism, and when each will next be looked at. In a multi tenant SaaS platform that data sits in the same database as another operator's, sometimes a competitor's, separated by software. For an industrial security reviewer, the question is not whether the vendor says tenants are isolated. It is where the isolation is enforced, what happens when a developer forgets it, and how the vendor proves both. This paper argues that the right answer is the query layer, and sets out what that means.

Why does multi tenant SaaS isolation matter more for industrial data?

All SaaS customers care about data segregation. Industrial operators have three reasons to care more.

The data is a vulnerability map. Commercial data leaking to a competitor is a business loss. A list of pressure vessels with remaining life under two years, with their locations, is a safety and security exposure. Regulators and insurers treat it accordingly.

The data has regulatory weight. Inspection records are the evidence that an owner-user has met its obligations under API 510, API 570, API 653 and the jurisdiction's pressure equipment rules. A record that another tenant could have read or, worse, altered is a record whose evidentiary value is in question.

The tenant boundary is also an organizational boundary. Operators run multiple sites, joint ventures and contractor relationships. The same platform may hold a contractor's own tenant and the operator's tenant, and the contractor's staff may hold accounts in both. Isolation has to hold between tenants even when the same human is a user of two of them, which is a harder problem than isolating strangers.

For these reasons a security review of an industrial SaaS platform should spend more time on isolation than on almost anything else, and should expect answers at the level of code paths rather than architecture slides.

Where can tenant isolation be enforced, and why does the layer matter?

Isolation can live at several layers, and most platforms have some of it at each. The layers differ in how they fail.

• Infrastructure. A database, schema or cluster per tenant. Failure mode: operational. Hundreds of databases drift in schema and patch level, backups are uneven, and a misconfigured connection string points one tenant's application at another's store. Strong when it works; expensive to keep working.
• Authentication. The login establishes which tenant the user belongs to and issues a token. Failure mode: the token is trusted downstream by code that does not re-check it, or a token issued before a permission change remains valid after it.
• API gateway. Requests are tagged with the tenant from the token and routed. Failure mode: the tag is a hint, not a constraint. Any handler that constructs a query without it reads across tenants.
• Application handlers. Each endpoint adds a tenant filter to its queries. Failure mode: there are hundreds of endpoints and one of them forgets. This is the most common real-world isolation failure in multi tenant systems, and it fails open.
• Repository or data access layer. Every query to the data store passes through one component that injects the tenant scope and rejects operations whose tenant does not match the request context. Failure mode: a bug in the chokepoint itself, which is one place to test rather than hundreds.
• Storage. Encryption at rest, per-tenant keys or per-tenant prefixes in object storage. Failure mode: protects against a stolen disk, not against a misfiled query.

The layer matters because of how it fails. Layers above the repository fail open: a forgotten filter returns another tenant's rows. The repository layer fails closed: a query without a tenant context cannot execute, and a write to the wrong tenant is refused. A platform can and should have controls at every layer, but the one that determines whether a forgotten filter is a breach or a logged error is the query layer.

What does isolation at the query layer look like?

Enforcement at the query layer is a design pattern with a few concrete properties. A reviewer can ask for each.

• A single chokepoint. All data access goes through one repository layer. There is no path from a handler to the database that bypasses it. This is a code structure claim and the vendor should be able to show it.
• Tenant context from the request, not the payload. The tenant is taken from the authenticated request context (the validated token) and attached to every operation. A tenant identifier supplied in a request body is never trusted to select the scope.
• Automatic scoping on reads. Every read query has the tenant clause added by the chokepoint, whether or not the caller supplied it. A caller cannot widen the scope.
• Rejection on mismatched writes. A write whose record carries a tenant different from the request's tenant is refused, and the refusal is logged with the actor, request identifier and both tenant values. Silent correction (overwriting the tenant field with the correct one) hides the bug that caused it; rejection exposes it.
• Request-level scoping through the stack. Background jobs, scheduled reports, exports and AI retrieval run under an explicit tenant context, not as a system user with global reach.
• Per-tenant audit chains. Audit events are hash-chained per tenant, so one tenant's audit log can be verified without reference to another's, and a tenant's export of its own log is complete in itself.
• Permission changes invalidate tokens. When a user's role or tenant membership changes, tokens issued under the old state stop working, so a user removed from a tenant cannot keep reading it until expiry.

intelliSPEC implements this pattern: tenant isolation is enforced at the repository chokepoint, writes with a mismatched tenant are rejected and logged, requests are tenant-scoped through the stack, and audit chains are per tenant.

How do you prove isolation to an auditor?

A control that cannot be evidenced is a promise. Isolation at the query layer generates evidence as a side effect, which is one of its advantages.

The rejection log. Every mismatched-tenant write that was refused is an event with an actor, a request identifier, an IP address, a user agent and both tenant identifiers. A log that is always empty is either a very clean codebase or a control that is not wired in; the auditor will want to know which.

The audit trail format. Every audited event, including reads, carries the tenant. An auditor can sample events for one tenant and confirm that no event references another tenant's records. With a per-tenant hash chain, the auditor can also run the verify routine and confirm that the chain is intact and nothing was removed.

The chokepoint itself. Show the data access layer and show that no other path to the store exists.

Token invalidation. Change a user's permissions, then attempt an operation with the old token, and show the refusal in the log.

Isolation testing. Automated tests that attempt cross-tenant reads and writes through every endpoint and assert refusal. The test suite is evidence; its results over releases are better evidence.

The SOC 2 Trust Services Criteria include logical and physical access criteria that require restricting access to authorized users and monitoring that access. Tenant isolation is one of the controls that address those criteria in a shared system. A vendor whose controls are mapped to the criteria should be able to point to the specific control, its evidence, and how it is tested, and should be clear about whether a report exists. intelliSPEC's controls are mapped to SOC 2 criteria and described in its Trust Center; the posture is stated there without overstatement.

The strongest isolation evidence is not a diagram of walls. It is a log of the times something tried to cross one and was stopped.

How does tenant isolation interact with SSO, roles, and API keys?

Isolation is not one control. It is the interaction of several, and gaps appear at the joins.

Single sign-on. When identity comes from the customer's own provider over OpenID Connect (Microsoft Entra, Okta or another), the platform trusts the provider for authentication but must still decide tenant membership itself. A user asserted by an identity provider must be mapped to a tenant by the platform's own record, not by a claim the provider could be misconfigured to emit.

Roles and permissions. Within a tenant, roles determine what a user can do. intelliSPEC has 991 permission entries in 25 categories, seven default roles per tenant and custom roles; segregation-of-duties rules prevent self-elevation to tenant administrator. Roles are tenant-scoped: a role held in one tenant confers nothing in another. A user with accounts in two tenants (the contractor case) has two distinct role sets, and switching tenant is itself an audited event.

Node-level entitlement. Within a tenant, access to the asset hierarchy can be narrowed to specific facilities or units. This is a finer control than tenant isolation and rests on it: node entitlement is applied after tenant scoping, never instead of it.

API keys. Programmatic access is where isolation is most often weakened, because keys tend to be long-lived and broad. Keys should be tenant-bound signed tokens tied to a role, so a key can never reach outside its tenant and never exceed the role it was issued under.

AI retrieval and actions. A retrieval layer that answers questions from the tenant's documents must run under the tenant context and read only that tenant's records. Actions that create or update records must go through the same repository chokepoint as a human user, so isolation and approval controls apply to them equally.

A reviewer should walk each of these joins and ask the same question: at this point, what determines the tenant, and can the caller influence it?

What questions should a security reviewer ask a vendor?

A short list that separates enforced isolation from described isolation.

1. Show me the code path. Where is the tenant scope applied to a database query? Is there any path to the store that does not pass through it?
2. What happens when a developer omits the tenant filter? Does the query fail, return nothing, or return everything?
3. What happens on a mismatched-tenant write? Is it rejected, corrected, or accepted? Where is it logged?
4. Show me the rejection log for the last quarter.
5. Does every audit event carry the tenant, including reads and exports? Is the audit log hash-chained per tenant? Can I run the verification myself?
6. When I remove a user from my tenant, when does their access end? Is the token invalidated or does it run to expiry?
7. How are API keys bound to tenant and role? Can a key be issued with broader scope than the role that issued it?
8. How do background jobs, scheduled reports and AI retrieval acquire their tenant context?
9. Is there a SOC 2 report, or are controls mapped to the criteria without a report? Either answer is acceptable if stated plainly; an evasive answer is not.

The answers to questions 1 through 4 tell a reviewer almost everything. A vendor that can show the chokepoint and the log has enforced isolation. A vendor that offers a diagram has described it.

How intelliSPEC handles it

intelliSPEC enforces tenant isolation at the repository chokepoint. Every data access passes through it, the tenant scope is taken from the authenticated request and applied to every operation, and a write whose record carries a mismatched tenant is rejected and logged rather than corrected. Requests are tenant-scoped through the stack, so exports, scheduled reports and Spectra retrieval run under an explicit tenant context.

Every event (create, read, update, delete, login, permission denied, tenant switch, data export and import, and system change) is written to an audit trail carrying actor, tenant, request identifier, IP address and user agent, hash-chained per tenant with a verify routine that recomputes the chain for auditors, and never auto-deleted. Access control is layered on top: 991 permission entries in 25 categories, seven default roles per tenant with custom roles and role templates, segregation-of-duties rules against self-elevation, node-level data entitlement over the asset hierarchy, and permission changes that invalidate stale tokens. Identity comes through OpenID Connect (Microsoft Entra, Entra B2C, Okta and generic OIDC) with TOTP multi-factor authentication and recovery codes, and API keys are tenant-bound signed tokens tied to a role, issued by the tenant itself.

Data is encrypted at rest with AES-256 in the database and object storage, in transit with TLS 1.2 or later, and offline columns on field devices are encrypted on the device. Controls are mapped to SOC 2 Trust Services Criteria and described in the Trust Center. Operators in oil and gas and power evaluating the platform can request the evidence described above, and intelliCOMPLY holds the procedures and attestations a reviewer will want alongside it.