NexusSecurity Overview
A concise orientation to the Nexus security model — customer-owned infrastructure, Entra ID identity, granular RBAC, secrets in your Key Vault, signed supply chain, and in-tenant audit — with pointers to the full security and compliance whitepaper.
This page is a short orientation to how Nexus by Stingray keeps you in custody of your data, secrets, and infrastructure. It summarizes the model in a few sections and points you to the deeper material. For the full architecture, threat model, secure-development and vulnerability-management program, incident response, and compliance posture, see the Security & Compliance whitepaper section — this page is a map, not the territory.
Customer-owned infrastructure
Nexus deploys as an Azure Marketplace managed application inside your own Azure subscription. The compute, the per-tenant PostgreSQL database, the Key Vault, the storage, and the network all live in your resource group, in the region you choose, under your existing Azure policy. There is no Stingray-hosted data plane — your business data is read, transformed, and stored entirely within your tenant. Stingray operates only a control plane that distributes the signed image and adapter bundles, leases short-lived signed licenses, and receives optional opt-in telemetry; it never holds your data, secrets, or query results. Deep dive: Tenant Isolation & Data Custody.
Identity and least-privilege access
Authentication is Microsoft Entra ID: users sign in with your existing identities and policies (Conditional Access, MFA), automation uses scoped app tokens or API keys, and the desktop client stores tokens in the OS keyring. Every action is then governed by granular, per-resource RBAC that applies equally to people and to automation — including AI agents on the embedded MCP server, which act strictly within the connecting identity's permissions. Execution roles allow controlled, audited privilege use with no standing elevation, and admin edit-locks protect sensitive bindings. Details: Roles & Permissions, Execution Roles, and Identity & Access.
Secrets and data custody
Connection credentials and signing material live in your Azure Key Vault, reached via managed identity. Database password authentication is disabled entirely — the per-tenant Postgres authenticates by managed identity, so there are no DB passwords to leak. Secrets are referenced by name, never returned in plaintext, and never written into pipeline code, exports, or version history. Networking is locked down at provision time with a per-tenant VNet, an NSG egress allowlist, and a private endpoint to the database. Details: Secrets Management and Connections & Isolation.
Supply-chain integrity
The connector adapters Nexus loads are distributed as signed bundles — each carries a signed manifest, an attestation, and a transparency-log entry, dual-signed with ES256 by two separate Azure Key Vaults, and is verified fail-closed before load. Your tenant only ever runs adapter code that passes verification. Full treatment: Supply-Chain Integrity.
Audit and accountability
Activity is recorded inside your tenant, where you control retention: runs, configuration changes, and access events are logged; pipeline runs capture full execution detail including complete tracebacks on failure; and AI actions through the MCP server are subject to the same RBAC and audit trail as any other principal. Only aggregated, opt-in telemetry (error and usage counts — never your data) can leave, and only if you turn it on. Details: Auditing & Telemetry.
Every governed action is attributable:
identity (Entra ID user or app) → RBAC check → action → audit record (in your tenant)
Program, threat model, and compliance
Security is a process as well as an architecture. Stingray runs a secure-development lifecycle, a vulnerability-management practice, and an incident-response process, and maintains an internal security-findings register and red-team exercises whose evidence is available to evaluators under NDA. Nexus inherits the certifications of the underlying Azure services it runs on; Stingray describes its own posture honestly and does not claim certifications or third-party assessments it does not hold. For the threat-model summary, secure-development and vulnerability-management narratives, incident response, the shared-responsibility model, and how to request evaluator evidence, read the Security & Compliance section: