Security overview

Sonora is a multi-tenant SaaS platform that ingests customer data from your CRM, conversation tools, support desk, and data warehouse. This page describes the controls that keep that data confidential, isolated to your workspace, and reachable only by people you authorize. It’s written for the security and procurement review that precedes a purchase.

For how to report a vulnerability, see the vulnerability disclosure program. For the outbound IP addresses to allowlist, see the network access page.

Compliance

Sonora maintains a SOC 2 Type II attestation. The current report, along with our maintained list of subprocessors, is available through the Sonora Trust Center.

Data encryption

Traffic between your browser and Sonora travels over HTTPS (TLS). Connections from Sonora out to your systems — Salesforce, Snowflake, BigQuery, and the rest — are made over each vendor’s encrypted API.

Secrets are encrypted at rest with AES-256-GCM. The data encryption key is derived per value using PBKDF2 (100,000 iterations, SHA-256) with a random salt, and each ciphertext carries its own random initialization vector and authentication tag. Keys are versioned, so a key can be rotated without re-encrypting historical data: old values decrypt under their original key version while new writes use the latest.

This application-layer encryption covers the credentials that would do the most damage if exposed:

• OAuth access and refresh tokens for connected integrations
• Integration credentials (the stored connection secrets for each data source)
• OIDC client secrets for tenants using their own identity provider

At the infrastructure layer, Sonora’s database runs on Google Cloud SQL, which encrypts all stored data at rest. The application-layer encryption above is a second layer over the most sensitive secrets, so those credentials stay encrypted even inside the database.

Authentication

Users sign in through their identity provider — there are no Sonora-managed passwords to breach. Supported methods:

• Google sign-in (the default for new workspaces)
• Microsoft sign-in
• Single sign-on (SSO) — as an enterprise option, a workspace authenticates against its own identity provider over OIDC or SAML
• Magic link — a one-time link emailed to the user

Magic links are single-use and expire 15 minutes after they’re issued. The token is never stored in plaintext (only a hash is kept), and clicking the link renders a confirmation step rather than logging in on the initial request, so email security scanners that prefetch links can’t consume the token before the human does.

Sessions are carried in a signed, HttpOnly cookie with SameSite=Lax, marked Secure in production. Sessions use a sliding 30-day window, refreshed on activity.

Access control and roles

Within a workspace, access is governed by roles. An administrator defines roles as a matrix of permissions and assigns them to users, so a member only sees and changes what their role allows. Permission checks run server-side on every protected route and action, not only in the UI.

Roles are managed under Settings → Roles.

Tenant isolation

Each customer is a separate tenant, and the platform is architected from the database up to prevent any cross-tenant data contamination. Isolation is enforced at the data layer, not only in application code, so one tenant’s data can never be reached from another tenant’s workspace.

Cross-tenant data access is explicitly in scope for the vulnerability disclosure program.

Subprocessors

Sonora runs on Google Cloud Platform, and its AI features run on Google Vertex AI within that environment. Customer data sent to the model for chat, summarization, and enrichment is processed through Vertex AI.

Beyond infrastructure, customer data flows only to the integration vendors you choose to connect. Connecting an integration is what authorizes that data flow; disconnecting it stops further flow and removes the stored credentials (see Data retention and deletion).

The current, authoritative list of subprocessors is maintained in the Sonora Trust Center.

Data retention and deletion

When you disconnect an integration, Sonora deletes that connection’s stored credentials, including the encrypted OAuth tokens, so it can no longer reach the source. You control the connected sources from Settings → Integrations, and you can also revoke Sonora’s access from inside the upstream system (for example, by disabling the OAuth app in your IdP or CRM).

Sonora deletes a tenant’s ingested customer data on request — specific records or your full data set, during the subscription or after it ends. Email security@usesonora.com or your account team to make a deletion request.

Vulnerability disclosure

Found a security issue? Email security@usesonora.com. The full policy — scope, safe harbor, and response timelines — is on the vulnerability disclosure program page.