Documentation / Administration

Secrets Management

How Nexus stores connection credentials and signing material in your own Azure Key Vault under managed identity, references them by name, never returns plaintext, disables database passwords entirely, and rotates on a NIST-aligned schedule.

Nexus connects to your databases, APIs, and SaaS systems using credentials that you control. This page explains where those credentials live, how Nexus references them at run time, why neither Stingray nor an AI agent can ever read their values, and how rotation works. It is written for administrators and security reviewers evaluating how Nexus handles sensitive material.

Where secrets live

Every secret Nexus uses is stored in your tenant's own Azure Key Vault, inside your Azure subscription. Nexus is deployed as a per-tenant Azure Marketplace managed application — the server, its database, and its Key Vault all run in infrastructure you own. Stingray operates no shared secret store and holds no copy of your credentials.

The Nexus server reaches Key Vault through an Azure managed identity, not a stored password or connection string. There is no long-lived vault credential sitting in a config file to leak: the platform's identity is granted access to the vault at provision time, and Azure issues short-lived tokens under the hood. Because secrets are scoped to your vault, you keep the full benefit of Azure's native controls — managed-identity access, access policies / RBAC, soft-delete and purge protection, diagnostic logging, and your own rotation and alerting.

Two categories of material live there:

Connection credentials — the values behind each bridge (database logins, API tokens, OAuth client secrets).
Signing material — the keys Nexus uses to sign and verify internal artifacts (for example, request/token signing). These are held in Key Vault with a short in-process TTL cache and a circuit breaker, so a transient vault hiccup degrades safely rather than failing every request, and a rotated key is picked up promptly.

No database passwords, anywhere

The per-tenant PostgreSQL Flexible Server that stores Nexus's operational state authenticates using an Azure AD managed identity. Password authentication is disabled at the server. There is no database password to store, rotate, leak, or find in a backup — the entire class of "leaked DB connection string" risk is removed by construction, not mitigated by policy. The same managed-identity model backs the internal Postgres workspace, which additionally runs under its own identity, structurally separated from the operational database.

Secrets are referenced by name, never by value

Nexus never stores a credential value inside a report, a pipeline, or its database. Connections are secret-derived: a bridge exists only because its secrets exist in Key Vault, and it is identified by name — for example a SQL Server connection named production. At run time, Nexus resolves the named secrets, opens the connection, and discards the values.

This has two consequences that matter to reviewers:

Authoring is value-free. When someone builds a report or pipeline, they choose a connection by name. They never type, paste, or see a password.
Export and history are value-free. Reports, pipelines, and their version history contain only references. You can share or version-control them without ever leaking a credential (see Version Control).

A pipeline references a connection by name:

    rows = await ctx.adapters.mssql.read(
        ReadQuery(bridge_id="production", ...))

Nexus resolves the "production" secrets from your Key Vault at run time.
The pipeline source never contains the host, user, or password.

Secrets never appear in pipeline code, and the sandbox that compiles pipelines strips file-I/O and unrestricted network access at the AST level — so a pipeline cannot read the vault directly or smuggle a secret out. Secrets reach a run only through the governed ctx.secrets / bridge-resolution path, resolved for the authenticated identity.

Values are never returned in plaintext

Key Vault never echoes a stored value back through any Nexus surface. Administrators can see which secrets exist and can configure or replace them, but reading an existing value back is not possible — not through the admin API, not through the desktop app, and not through the MCP interface used by AI agents.

This is enforced at the lowest layer rather than by convention: there is no API path, parameter, or "debug" mode that returns a stored secret. The only operations are write, delete, and test-connection. Test-connection proves a credential works without ever revealing it.

Two scopes: service and personal

Nexus supports two credential scopes so shared and personal access stay separated. The full behavior is on Connections & Isolation; in brief:

Scope	Owned by	Who can use it	Managed by
Service	The tenant	Anyone whose role permits running the report or pipeline	Administrators
Personal	One user	Only that user	That user

A user cannot resolve another user's personal credential, and an administrator cannot read its value either. Resolution always uses the identity from the caller's validated sign-in token; there is no parameter anywhere by which a caller names whose credentials to use. Non-interactive runs (webhooks, background triggers) have no human identity and therefore can never reach a personal credential — they fall back to service scope or fail closed, never widening access.

AI agents cannot read secrets

When an AI assistant connects to Nexus over MCP, it operates within the same boundary as every other client and the same RBAC engine. It can run reports and pipelines that use connections, but it cannot enumerate secret values, cannot resolve another user's credentials, and cannot extract a credential through query results. Agents work with named connections and data — never with the underlying secrets.

Rotation

Because credentials are referenced by name, rotation is straightforward and non-disruptive. Replace the value behind a named connection — directly in Azure Key Vault or through the Nexus admin surface — and every report and pipeline that references that name immediately uses the new value on its next run. No report needs to be re-authored and no pipeline needs to be re-edited, because none of them ever contained the old value. After rotating, run a connection test to confirm the new value works before relying on it.

Signing material is rotated on a NIST-aligned 90-day cadence. Because the server holds only a short-TTL cache of signing keys backed by the vault, a rotation propagates quickly without a redeploy, and old material ages out. Connection credentials should follow your own organization's rotation policy; the name-based indirection means you can rotate as aggressively as your security program requires with zero authoring churn. Azure Key Vault's soft-delete and purge protection give you a recovery window if a rotation needs to be rolled back.

Summary

Secrets and signing keys live in your Azure Key Vault, in your subscription, reached via managed identity — no stored vault password.
Database passwords are disabled entirely; Postgres authenticates by managed identity.
Connections are referenced by name; values never enter reports, pipelines, code, history, or the database.
Stored values are never returned in plaintext by any interface — only write, delete, and test.
Service and personal scopes keep shared and individual credentials separate, with strict per-user isolation.
AI agents and Stingray never see credential values.
Rotation is a single update behind a name; signing material rotates on a NIST 90-day cadence.