Security
Tenant Isolation
NNIPA is multi-tenant — many organizations share the same platform. Tenant isolation is the guarantee that lets that be true without one customer's data ever being visible, queryable, or discoverable by another.
How isolation is enforced
Enforced at the query engine, not the edge
Every dataset, analysis, and job carries its owning tenant, and the shared query engine every feature reads through applies that scoping to every request — not just the ones that happen to check at the API boundary.
No cross-tenant visibility, ever
A user with access to two organizations sees two completely separate catalogs, job queues, and result histories. Nothing about one is reachable from the other, even by a direct link or a guessed identifier.
Workspaces segment within a tenant
Workspaces group datasets and analyses for a team inside your organization — a narrower boundary than tenant isolation, and one your organization controls rather than NNIPA.
- Background work — statistical jobs, ML training, scheduled workflows — carries the same tenant scoping as an interactive request. A long-running job never becomes a cross-tenant leak just because it executes later.
- Tenant isolation is separate from, and sits underneath, the role and dataset permissions described in Authorization — those control access within your tenant; this is what keeps tenants apart in the first place.
- Publicly shared dashboards are the one deliberate exception — a share link is scoped to exactly the dashboard it was created for, not to the tenant as a whole.