Security at Nivora

Access control

Nivora is invite-only. An account cannot be used until it is approved and linked to an organization by an administrator. Within an organization, access is role-based — admin, editor, and viewer — and per-deal collaboration is granted at the viewer or editor level, so people see only the deals they are given.

• Organization isolation. Every organization’s deals and documents are isolated from every other organization at the database layer using PostgreSQL row-level security — not application code that could be bypassed. The isolation is enforced on the underlying tables themselves.
• “Keep Nivora out” support toggle. By default, Nivora’s support team can reach an organization’s data to help operate the account. An organization admin can switch that cross-organization access off for their own organization at any time; billing and account-identity functions continue to work, but Nivora support loses visibility into the organization’s deal data until it is switched back on. Every change to this setting is recorded.
• Read-only support access. When support does look at an account, the “View As” tool is read-only, admin-gated, and every session is written to an immutable impersonation log — administrator, target, and timestamps — so support access is always accountable after the fact.

Authentication

Sign-in is email and password through our authentication provider (Supabase Auth), which stores passwords only as salted hashes — never in plaintext, and never visible to us.

• Two-factor authentication. Nivora supports one-time-code two-factor authentication delivered by email, with an option to trust a device so you are not prompted on every sign-in. One-time codes are stored only as peppered hashes, and the trusted-device token is a signed, hashed cookie — the raw values are never kept.
• Enforcement. Two-factor authentication can be enforced organization-wide by a configuration switch; once enabled, the requirement is applied both in the application and directly at the data layer, so it cannot be skipped by calling the API.

How your data is protected

• Encryption. Data is encrypted in transit (TLS) and at rest by our infrastructure providers (Supabase on AWS). Card details never touch our servers — payment data is entered directly with Stripe.
• Tenant isolation on every table. Row-level security is enabled on the application’s tables, so a query can only ever return rows the signed-in user’s organization is entitled to. Cross-organization visibility exists only for Nivora’s super-admin role, and even that is subject to the per-organization “keep us out” toggle above.
• Immutable audit trail. Changes to a deal are written to a change log — one record per changed field, capturing who made the change, the old and new values, and when. The log is a product feature your organization can review, and it is protected against tampering at the database layer.
• Ownership and export. Your organization owns the documents it uploads and the underwriting it builds. You can export your work, and if your organization ends its relationship with us we will delete or return organization data on request, subject to legal retention requirements.

Application and network security

The application ships with a strict security posture at the edge:

• Content Security Policy. A restrictive CSP limits script, connection, and frame sources to a short allow-list, and frame-ancestors 'none' plus X-Frame-Options: DENY prevent the app from being embedded or clickjacked.
• Hardened response headers. X-Content-Type-Options: nosniff and a strict Referrer-Policy are applied to every response.
• Bot protection. Sign-in and sign-up are protected against automated abuse (Cloudflare).
• Server-only secrets. Privileged keys — the database service role, the AI provider key, billing keys — live only in serverless functions and are never shipped to the browser.

AI and document processing

When you upload an offering memorandum or use another AI-assisted import, the document is processed by Anthropic’s Claude API under terms that do not permit the provider to train models on your data. Extracted figures are returned with page-level citations and are always shown to you for review before they become part of your underwriting — the model never silently writes numbers into your model. We do not use your organization’s deal data to train AI models.

Subprocessors

We rely on a small set of infrastructure providers to run the Service. The full list, with the role each one plays, is maintained in our Privacy Policy:

• Supabase — database, authentication, and file storage.
• Vercel — application hosting, serverless functions, and cookieless analytics.
• Anthropic — AI document extraction, as described above.
• Sentry — error monitoring.
• Cloudflare — bot protection on sign-in and sign-up.
• Microsoft — transactional email (two-factor codes, invitations, and account notices).
• Stripe — subscription billing and payment processing.

Reporting a vulnerability

If you believe you have found a security issue in Nivora, please report it to your Nivora representative or your organization administrator, who can reach our team directly. We take reports seriously, will acknowledge them promptly, and ask that you give us a reasonable opportunity to investigate and remediate before any public disclosure.

What we don’t claim

We describe the controls we actually run rather than badges we don’t hold. Nivora does not today publish a third-party audit report such as SOC 2 or ISO 27001; formal attestation is on our roadmap as our customer base of institutional funds grows. In the meantime, we are happy to walk a fund’s vendor-security review through the controls on this page and answer follow-up questions.

This overview is a good-faith description of current practice, not a contractual commitment; the binding terms are in our Terms and Privacy Policy. It is pending final review by counsel and may be updated as the platform evolves.