Tenant isolation and data residency

When you evaluate an AI assistant for your organization, one question sits above all the others: does our data stay ours? Not “mostly.” Not “unless something goes wrong.” Yours — separate from every other organization on the platform, never used to train a public model, never visible to anyone outside your own people.

This page explains, in plain terms, how SUPERWISE Chat keeps your organization’s data isolated, where that data lives and travels, and the controls that make “your data stays yours” a property of the system rather than a promise on a slide.

What “tenant isolation” actually means

Every organization on SUPERWISE Chat is a tenant — a sealed boundary around all of that organization’s data: its conversations, documents, knowledge collections, memory, settings, audit records, and user list. Your tenant is yours alone.

The core guarantee is simple to state and worth being precise about:

No request made by a user in one organization can ever read, write, or even observe the existence of another organization’s data. Tenant boundaries are enforced on the server, on every single request — not in the browser, and not by convention.

This matters because the weakest form of “isolation” is the kind that depends on the application remembering to filter correctly every time. SUPERWISE Chat does not rely on good intentions. Every piece of data carries the identity of the tenant it belongs to, and every data access is scoped to the tenant of the person making the request. A query can only ever return rows that belong to your organization. There is no “show everything” path available to a normal user, an administrator, or even a misbehaving feature.

A diagram in words

Picture a request as it travels through the system:

You sign in. Your identity provider (your company’s SSO) issues a signed token that names you and names your organization. The server verifies that token on arrival — it trusts your sign-in, not the browser’s word for who you are.
The server stamps your organization onto the request. From that point on, the request carries your tenant identity the way a passport carries a nationality. It cannot be quietly swapped.
Every data lookup is filtered by that identity. When Chat reads your conversations, searches your knowledge, or recalls a memory, the lookup is automatically narrowed to your organization. Another organization’s rows are simply not in the result — they were never reachable.
Caches and audit trails are kept separate too. Even the temporary, behind-the-scenes stores that make Chat fast are partitioned per organization, so a fast answer to one organization can never become a fast answer leaked to another.

The effect is that isolation is not a single wall you could imagine someone climbing over. It is woven into how data is named and retrieved at every layer.

The delivered posture, stated plainly

We think the right way to talk to a security team is to be exact about what is enforcing your isolation today versus what is being strengthened over time. So here it is, without hedging.

Today, tenant isolation is enforced in the application server on every request. Each data operation — every read, every write, every cache lookup, every audit query — is explicitly scoped to the requesting user’s organization. This is the active, live control, and it is covered by an automated cross-tenant isolation test suite that runs continuously and specifically tries to make one organization see another’s data. Those tests pass.

We are also rolling out a second, deeper layer of isolation enforced inside the database itself. This layer is built and verified, and it is being enabled through a deliberate, reversible, staged process rather than flipped on overnight. When fully in place, it means the database itself refuses to return another organization’s rows — a belt-and-suspenders guarantee that does not depend on the application asking the right question. Until that rollout completes, the application-layer control above is what protects your data, and it does so completely.

Why two layers, and why the care? Defense in depth is the whole point: the application layer enforces isolation by always asking scoped questions; the database layer (when on) enforces it even if a question were ever asked without scope. The deeper layer is powerful enough that turning it on carelessly could make data appear to vanish for legitimate users. So we enable it gradually, watch it under real traffic, and keep instant rollback available at every step. Conservative sequencing here is a feature, not a delay — it is how a strong control gets turned on without ever risking your access to your own data.

The honest summary for your records: isolation is real and enforced now at the application layer; a stronger database-level layer is built and being enabled through a gated, reversible process. We would rather you have that exact picture than an overstated one.

Administrators see only their own organization

Isolation is not just a property of the data store — it shapes what every role can do.

A tenant administrator manages their own organization and nothing else. There is no “see all customers” view available to a customer administrator.
Roles follow a clear hierarchy, and a person can only grant access at or below their own level — so privileges cannot be quietly escalated. (See Users and roles for the full model.)
Sensitive oversight is separated from the ability to change things: a compliance reviewer can be given read-only visibility into activity and audit records without any power to modify configuration or content.

There is exactly one tightly controlled exception, and it exists for platform operations support, never for customer-to-customer access: a platform operator may, when assisting, open a time-boxed, fully audited support context. It expires automatically after a few hours, is recorded as a distinct event, and can be revoked early. It is never granted to ordinary organization roles, and it does not create any standing ability to browse across customers.

Your data is processed by a private model — never a public AI

A common and reasonable worry: “If we type something into an AI, does it get sent off to a public chatbot and absorbed into someone’s training data?”

For SUPERWISE Chat, the answer is no.

Your conversations are processed by a private model environment dedicated to the platform, not by a consumer AI service that retains and learns from what you type.
Your content is not used to train public models. Your prompts, documents, and the assistant’s responses are not fed back into any public model’s training.
What the assistant can reach is governed. When an assistant draws on external sources (for example, a web search), that capability is explicitly permission-gated and confined to an approved list — it is not an open, unrestricted pipe to the internet. Retrieved content is also screened before it is used. (See Why it said no for how that review feels in practice, and Your privacy for the user-facing view.)

The practical upshot: the safe-at-work feeling your people get from Chat is backed by architecture, not just policy. Your organization’s words stay inside your organization’s boundary.

Data residency and where data lives

Within your tenant, data is organized so that residency and retention are predictable:

Conversations and knowledge live in your tenant’s partition of the platform’s managed database and document stores, always tagged with your organization’s identity.
Memory that the assistant builds up about your team’s preferences and context is likewise tenant-scoped and, where it is more than purely operational, subject to the consent controls your users hold.
Audit records of governance decisions, role changes, and settings changes are retained for compliance and are, by design, append-only for sensitive categories — settings-change history and role-change history, for instance, cannot be edited or deleted by an administrator.
Short-lived operational data (such as session tokens and temporary logs) expires automatically on a defined schedule.

If your organization has specific data-residency obligations — a region where data must remain, a retention duration you must meet, or a deletion timeline you must honor — your deployment can be configured to meet them. For the customer-facing controls you operate yourself, see DSAR and deletion. For the formal commitments and the processing addendum, see Data Processing and the DPA.

A note on identity

Isolation is only as trustworthy as the front door. SUPERWISE Chat authenticates every user through your own identity provider using standard, signed single-sign-on tokens, and it verifies on the server that each token was issued for this service and names a recognized organization. A token minted for a different system cannot be replayed to gain access here, and an unknown organization is refused rather than silently admitted. Your IT team controls who is let in; Chat enforces what each of those people can see once they are.

For setup, see Identity and SSO.

The bottom line for a security review

Isolation is enforced on the server, on every request — today. It does not depend on the browser or on the application remembering to filter, and it is continuously tested by a suite designed to break it.
A deeper, database-level isolation layer is built and being enabled through a careful, reversible, staged rollout. We will not overstate it as the live control until it is fully on; the application-layer control protects you in the meantime.
Administrators are scoped to their own organization. Cross-customer access is not a feature; the single operations-support exception is time-boxed, audited, and revocable.
Your data is processed by a private model and is never used to train public AI.
Sensitive audit trails are append-only and cannot be quietly deleted.

If you need any of these statements in a form suitable for a vendor questionnaire or a procurement review, see Security statement and Data Processing and the DPA, or ask your account contact.