NexusTenant Isolation & Data Custody
How Nexus keeps custody of your data — per-tenant Postgres, Container App, Key Vault and VNet; managed-identity database auth with no passwords; an isolated internal workspace database; run-as-user credential isolation; and an env-scrubbed process-isolation worker.
This page is for reviewers who need to understand exactly how Nexus isolates one tenant from every other tenant, and how it isolates trust within a tenant. It covers the per-tenant infrastructure boundary, managed-identity database authentication, the structurally-isolated internal workspace, run-as-user credential isolation, and the process-isolation model for the pipeline runtime. Where a control is rolling out rather than universally live, this page says so.
Isolation between tenants is Azure subscription isolation
Nexus does not implement its own multi-tenant data partitioning, because it does not run a multi-tenant data store. Every tenant is a separate Marketplace managed-application deployment into a separate Azure subscription. The Container App, PostgreSQL server, Key Vault, storage account, and VNet are all per-tenant resources. Two customers share no database rows, no Key Vault, and no network path.
This means the isolation guarantee between customers is not a Nexus feature you have to audit — it is the isolation Azure already provides between two subscriptions, which your security team already trusts and already knows how to reason about. There is no "tenant ID" column in a shared table anywhere that a bug could leak across.
| Resource | Scope | Isolation mechanism |
|---|---|---|
| Nexus server (Container App) | Per tenant | Separate compute in your resource group |
| Operational database (PostgreSQL Flexible Server) | Per tenant | Private endpoint, managed-identity auth, your VNet |
| Key Vault | Per tenant | Your Key Vault, your access policies, Stingray has none |
| Internal workspace database | Per tenant | Separate database + separate managed identity |
| Virtual network + NSG | Per tenant | Your VNet, egress allowlist |
| Version-control repo + pipeline state | Per tenant | Azure Files in your storage account |
Database custody: managed identity, no passwords
The per-tenant operational database is an Azure Database for PostgreSQL Flexible Server. It is configured so that:
- Password authentication is disabled at the server. There is no database password to store, rotate, leak, or find in a config file. The Nexus Container App authenticates using an Azure AD managed-identity token.
- Access is over a private endpoint. The database is not exposed to the public internet; the Container App reaches it inside your VNet.
- The identity is user-assigned and least-privilege. It is granted what Nexus needs and nothing standing beyond that.
Because auth is identity-based rather than secret-based, the common failure mode — a leaked connection string granting database access — does not exist here. There is no long-lived database credential to leak.
The internal workspace is structurally isolated from operational tables
Nexus ships a baked-in per-tenant internal workspace: a Postgres-backed scratch database that pipelines and reports use for staging, materialization, and intermediate results via ctx.workspace. This is a powerful convenience, and it is deliberately walled off from the system's own operational data.
The isolation is structural, not merely permissioned:
- The workspace is a separate database with its own managed identity, distinct from the identity Nexus uses for its operational tables.
- UQL executed against the workspace literally cannot address the operational database. There is no cross-database query path from workspace context into the tables that hold reports, pipelines, RBAC grants, secrets metadata, or audit records. It is a hard wall, not a WHERE-clause filter that a crafted query could slip past.
The practical consequence: a user or agent authoring workspace SQL — even a malicious one — cannot pivot from "I can write to my scratch tables" to "I can read or tamper with the platform's own control tables." The two live in different databases reached by different identities.
Run-as-user credential isolation
A bridge is a named connection to a data source (for example (mssql, "production")). Bridges exist because their secrets exist in your Key Vault. Nexus enforces a strict rule about whose credentials a given execution may use.
- Service bridges are owned by the tenant, managed by admins, and usable by anyone whose RBAC permits the relevant report or pipeline.
- User bridges are owned by a single user and usable only by that user — a user can supply their own keys without any admin ever seeing them.
Credential resolution happens in a single server-side function. There is no request parameter, anywhere in the API, by which a caller can name whose credentials to resolve. The resolver only ever resolves secrets belonging to the authenticated identity. A report or pipeline declares a bridge_mode (service_only, user_only, or user_then_service), and the resolver fails closed when no eligible identity is present.
This is the control that prevents the classic confused-deputy attack: user A cannot craft a call that executes under user B's credentials, because the identity whose secrets get resolved is always the authenticated caller, decided server-side, never supplied by the request.
The same discipline governs the embedded MCP server. An AI agent connects as a specific identity and resolves only that identity's bridges — it cannot borrow another principal's connector credentials. See Identity & Access and Connections & Bridges.
Process isolation for the pipeline runtime (rolling out)
Pipelines are Python modules (async def run(ctx)) compiled under a sandbox: an import allowlist is enforced, and exec/eval, file I/O, and unrestricted network access are stripped at the AST level before code is accepted. That AST-level sandbox is the first line of defense and applies to all authored pipeline code.
On top of that, Nexus is deploying a process-isolation model that hardens the runtime against a sandbox escape:
- Pipelines execute in a worker process whose environment is scrubbed of signing keys and managed-identity material. The worker holds no secrets that would let an escaped payload mint a managed-identity token, reach Key Vault, or forge a request signature.
- The worker obtains the specific bridge secrets a run legitimately needs brokered over a data-only IPC channel from the main process — it never gets a general credential to the vault.
- Bridge secrets are delivered as data, not as ambient environment or a live vault handle, so a compromised pipeline sees only what its run is entitled to and cannot enumerate the tenant's secret material.
Status and honesty note. This process-isolation model is live on the stingraytest tenant and is rolling out; it is an architectural control being deployed, not a universal GA guarantee already active on every tenant. The AST-level import sandbox described above applies everywhere today; the env-scrubbed brokered-secret worker is the layer whose rollout is in progress. Ask your Stingray representative for the current status on a specific deployment.
Version history and recoverability of custody
Your authored assets — pipelines, reports, sites, skills — are stored in a per-tenant git repository on Azure Files, with history, diff, and restore available over both REST and MCP. Writes are multi-replica-safe via an advisory lock; reads are lock-free. Because Nexus operational state is a rebuildable projection over a versioned store, configuration and authored assets carry inspectable history you control. Point-in-time restore of the underlying PostgreSQL Flexible Server is available through Azure-native tooling. See Version Control and Backup & Disaster Recovery.
What this does and does not do
It does: keep every byte of your business data, secrets, and history inside your Azure tenant; make cross-tenant leakage a non-event because there is no shared store; make cross-user credential theft structurally impossible via server-side resolution; wall the workspace off from operational tables at the database boundary.
It does not (yet, universally): guarantee env-scrubbed process isolation on every tenant — that layer is rolling out, live on stingraytest. And it does not remove your responsibility for the surrounding Azure RBAC, network policy, and who you grant subscription access to; those remain yours to govern.