Documentation / Security & Compliance

Security Architecture

The complete Nexus security model on one page — tenant-owned deployment with no Stingray data plane, the control-plane trust boundary, a data-flow inventory, and exactly what Stingray can and cannot access.

This page is the security architecture reference for Nexus by Stingray. It is written for a skeptical security reviewer who needs to reason about trust boundaries, data custody, and blast radius before approving a deployment. It describes the whole model on one page: where Nexus runs, the single trust boundary that matters (the control plane), a data-flow inventory, and a precise account of what Stingray can and cannot reach. The remaining pages in this section go deep on each control.

The short version: Nexus is a single-tenant application that runs entirely inside your Azure subscription. Stingray ships software and operates a metadata-only control plane. Stingray operates no data plane, holds none of your secrets, and cannot reach your business data. Your compliance boundary does not have to expand to include a third-party SaaS.

The deployment model: tenant-owned, no vendor data plane

Nexus is delivered as an Azure Marketplace managed application that you install into your own Azure subscription. Every component that reads, transforms, holds, or exposes your data is provisioned into your resource group, in the Azure region you choose, under your existing Azure Policy, RBAC, and network governance.

Concretely, a Nexus deployment provisions, per tenant:

an Azure Container App running the Nexus server image (REST API, query engine, pipeline runtime, embedded MCP server);
an Azure Database for PostgreSQL Flexible Server for operational state (reports, pipelines, configuration, run history, audit records), reached over a private endpoint with managed-identity authentication and password auth disabled;
a per-tenant Azure Key Vault holding all connector credentials and signing material;
a per-tenant virtual network with an NSG egress allowlist at the network layer, complementing an application-layer egress allowlist and SSRF checks;
Azure Files for pipeline state and the per-tenant version-control repository (git history for pipelines, reports, sites, skills);
a user-assigned managed identity that the Container App uses to reach Postgres, Key Vault, and storage — there are no standing passwords for infrastructure.

There is no shared, multi-tenant Stingray database in this picture. Two tenants deployed from the same Marketplace offer share no data plane, no database, no Key Vault, and no network. Isolation between customers is the isolation Azure already gives two different subscriptions.

The one trust boundary that matters: the control plane

Stingray operates a small, shared control plane (Azure Functions) that every tenant talks to. This is the only Stingray-operated component in the architecture, so it deserves precise scrutiny.

What the control plane does:

distributes the signed Nexus server image and signed adapter bundles (the software supply chain — see Supply-Chain Integrity);
issues short-lived, signed licensing leases;
publishes update notifications and the connector catalog;
receives optional, opt-in operational telemetry (error and usage counts — never your data).

What the control plane can never reach: your business data, your connector secrets, your Key Vault contents, your query results, your reports, or your pipeline definitions. None of these ever leave your tenant, and none are transmitted to the control plane by any code path.

Two design choices make this boundary robust rather than merely a policy promise:

Licensing is verified locally. Nexus validates license leases inside your tenant against a published public key baked into your deployment. The server does not need a live callout to the control plane to keep working, so a control-plane outage or compromise cannot silently reach into your tenant to enforce, disable, or exfiltrate.
The data path never traverses Stingray. Query and pipeline results return directly from the Nexus server (in your tenant) to the calling client. Stingray is never an intermediary hop for data.

Communication from your tenant to the control plane is server-to-server authenticated and carries only operational metadata.

What Stingray can and cannot access

Stingray cannot access	Stingray does operate
Your business data (ERP, SaaS, database records)	A shared control plane that distributes the signed Nexus image and adapter bundles
Your connector secrets and credentials	Short-lived, signed license leasing
Your Key Vault contents and signing keys	Update notifications and the connector catalog
Your query results, reports, dashboards	Optional, opt-in operational telemetry (error/usage counts — never data)
Your pipeline source and run history	—
Your PostgreSQL database and its contents	—
Your network, VNet, or private endpoints	—

Stingray personnel have no standing credential into your tenant. There is no vendor "break-glass" account provisioned by the managed application, no shared admin identity, and no Stingray-held key that decrypts your Key Vault. Operational access to your deployment is governed by your own Azure RBAC — you decide who, including whether any Stingray engineer is ever granted scoped, audited, time-boxed access for support.

Data-flow inventory

The following is the complete set of data flows in a running deployment. Anything not listed here does not happen.

1. User / automation → Nexus server (in your tenant)
   OAuth2 + PKCE (users) · scoped app tokens / API keys (automation)
   Transport: HTTPS. No data leaves your tenant.

2. Nexus server → your data sources (SQL Server, NetSuite, Monday, Postgres, ...)
   Credentials resolved from YOUR Key Vault. SSRF-checked, egress-allowlisted.
   Results return to the Nexus server, then to the caller. Stingray not involved.

3. Nexus server → per-tenant PostgreSQL (operational state + audit)
   Managed-identity token over a private endpoint. Password auth disabled.

4. Nexus server → per-tenant Key Vault (secret + signing material)
   Managed-identity token. Short-TTL cache with a circuit breaker.

5. Nexus server → Azure Files (pipeline state + version-control repo)
   Managed identity. Multi-replica-safe writes via advisory lock.

6. Nexus server → Stingray control plane (updates, catalog, license)
   Server-to-server auth. Operational METADATA ONLY — never your data.

7. AI agent (MCP client) → Nexus server embedded MCP server
   Same identity, same RBAC, same audit trail as any other principal.

Flows 1–5 and 7 are entirely inside your Azure tenant. Flow 6 is the only flow that leaves your tenant, and it carries no business data.

The trust model in one paragraph

You trust Azure (you already do). You trust the Nexus software you chose to install — and you can verify it: the image and every adapter are cryptographically signed and verified fail-closed before they run (see Supply-Chain Integrity). You trust that Stingray will ship honest software and respond to vulnerabilities — and you can inspect the program behind that (see Secure Development & Vulnerability Management). You do not have to trust Stingray with a copy of your data, your secrets, or a standing key into your tenant, because the architecture never gives Stingray any of those.

Defense in depth inside the tenant

Even though the whole deployment is yours, Nexus does not treat the tenant boundary as the only control. Inside your tenant it enforces additional, independently-reasoned layers:

Identity and RBAC on every action, for both human and application principals, including the embedded MCP server (see Identity & Access).
Credential isolation so a user's connector secrets can never resolve for another identity, and an internal workspace database that UQL structurally cannot use to reach operational tables (see Tenant Isolation & Data Custody).
A sandboxed pipeline runtime — pipelines are Python compiled under an import allowlist with exec/eval/file-I/O/unrestricted-network stripped at the AST level, plus a process-isolation model (an env-scrubbed worker holding no signing or managed-identity secrets) that is live on the stingraytest tenant and rolling out.
Network egress control at both the application layer (allowlist + SSRF checks on all outbound HTTP) and the network layer (NSG allowlist), so a compromised pipeline cannot freely reach the internet.

Each of these is detailed on its own page in this section.

What this model does and does not give you

It gives you: a platform whose blast radius on a Stingray-side incident is bounded to "a bad software update you can decline," not "our vendor lost our data." It gives your data residency, sovereignty, and network isolation the exact posture your Azure subscription already has. It gives you a supply chain you can cryptographically verify.

It does not magically certify your deployment: the security of the surrounding subscription, network policy, identity configuration, and operational access is yours to run, as in any Azure-native architecture. Nexus is designed to make that boundary honest and small, not to remove your responsibility for it. See Compliance & Shared Responsibility for the split.