In one paragraph. Nabla-X is not independently certified — there is no SOC 2 report, no ISO 27001 certificate and no third-party HIPAA assessment yet. What exists is a set of technical controls you can verify from outside: database-enforced tenant isolation, encrypted credentials, an audit trail on every governed action, a policy gate in front of every generated query, and an on-premises appliance that makes no outbound connection at all. Everything below is one of those two things: a control you can test, or a gap we have named.
What is enforced
Tenant isolation, enforced by the database
Every table that holds customer data in the platform schema carries Postgres row-level security, set to FORCE, keyed on the organisation and user of the current request. The application connects to the database as a dedicated role that cannot bypass RLS; the privileged role is used only for migrations, background workers and session resolution before an organisation context exists. This matters because a service role with bypass rights makes every policy decorative — which is exactly the state we found and fixed during the build, and why the health check now reports it explicitly.
The public REST surface of the underlying database is locked as well: the tables the dictionary and anomaly engines use are not readable with the public key that ships to the browser.
Credentials and encryption
- Data-source connection credentials are encrypted at the application layer with AES-256-CBC and a per-record IV, under a key derived with scrypt from a secret that lives only in the deployment environment. They are decrypted per request, never returned to the browser, and never logged.
- Only a data-source identifier crosses the browser after setup — never a password.
- Data at rest is encrypted by the database provider; data in transit is TLS everywhere on the hosted platform.
- On the appliance, the same encryption key is generated by the installer and stays on the host.
What an AI is allowed to do with your data
- Read-only. Generated SQL must begin with
SELECT; write and DDL keywords are refused, an injection-pattern check runs on the text, and the statement is parsed before it can execute. - Policy gate. Columns marked as PII in your data dictionary block generation (or warn, if you choose) before a query is produced. The decision, and the violation if any, is written to the audit trail. The default with no configured policy is to block.
- Grounding, not guessing. Generation is grounded in your own reviewed definitions; unapproved PII columns are withheld from the model entirely.
- Model routing is per organisation. A cloud provider is used only if your organisation configured one. An organisation flagged offline-only, and every appliance, refuses cloud providers outright — the refusal is logged.
Audit trail and evidence
Every governed action — sign-in, data-source changes, query generation and feedback, anomaly acknowledgement, policy and evaluation changes, member changes, exports — is written by the server to an organisation-scoped audit log with actor, action, resource and metadata. Organisation admins read it org-wide; members see their own actions. It is exportable as JSON or CSV together with data-source and anomaly history, and the export itself is an audited event.
Access
- Three roles inside an organisation — Viewer, Data Engineer, Org Admin — checked on every API call from the database record, not from a token claim alone.
- Hosted sign-in is handled by Clerk; Nabla-X never sees or stores your password.
- Appliance sign-in is local: bcrypt-hashed passwords, signed session cookies, a forced password change on first sign-in, and throttled attempts. Accounts are created by your administrator; nothing is emailed.
- Platform-side operational data (the enquiries inbox) is visible only to a named allow-list of Nabla-X staff, and not at all on an appliance.
Deployment options
| Option | Where your data goes | Who can see it |
|---|---|---|
| Hosted | Nabla-X's hosted database; the model provider you configure, for the question, schema and dictionary context of each request | Your organisation; Nabla-X operators for support; the provider you chose |
| Private VPC | Your servers. Local models by default; TLS on your hostname | Your organisation |
| Air-gapped appliance | Nowhere. No outbound connection at runtime; the health check fails if a required model is not present locally | Your organisation |
The appliance is configured and downloaded from the deployment console.
Check it yourself
- Health. /api/health is public and reports, among other checks,
rls_enforced— whether the role the application is running as can bypass row-level security. On an appliance it also lists each required local model. - Evidence. Any org admin can export the audit trail from the Audit Log console and reconcile it against what their team did.
- Offline. On an appliance, disconnect the host from the network and keep using it. On Linux,
tcpdumpon the stack should print nothing. - Isolation. Create two organisations and confirm neither can read the other's data sources, policies or audit rows. We test this the same way.
Third parties that process data
For the hosted platform only. An appliance uses none of these.
| Provider | Purpose | What it receives |
|---|---|---|
| Vercel | Application hosting, edge network, site analytics | All requests to nablax.in; anonymised page-view analytics |
| Supabase (AWS) | Managed Postgres | All platform data, encrypted at rest |
| Clerk | Authentication for the hosted platform | Email, name, password hash, session |
| Your chosen model provider (Anthropic, OpenAI, Google, Mistral) via Vercel AI Gateway | SQL generation, enrichment, narratives — only when your organisation selects a cloud provider | The question, the relevant schema and dictionary context, and computed factors for narratives. Query results are never sent. Dictionary enrichment does send up to three sample values per profiled column — mark PII columns before enriching, or run enrichment on a local model. |
| Resend; Twilio or Meta WhatsApp | Transactional email; enquiry notifications to Nabla-X | Contact-form fields; invite emails |
The privacy policy covers the website and forms in the same detail.
What we do not have yet
These are the questions we expect, answered before they are asked.
- No SOC 2 or ISO 27001 report. The hosting and database providers hold their own; Nabla-X has not been audited as an organisation.
- No third-party HIPAA assessment. The controls above are the ones a HIPAA programme relies on, but nobody independent has attested to that. For PHI, the appliance keeps data inside your boundary; a Business Associate Agreement for the hosted platform is a conversation, not a checkbox.
- No third-party penetration test has been performed yet.
- No SSO or SCIM. Hosted sign-in is through Clerk; the appliance uses local accounts.
- No customer-selectable data residency on the hosted platform. The appliance is the answer for residency today.
- No contractual uptime SLA on the hosted platform.
- No self-service password reset on the appliance — an administrator issues a temporary password.
Reporting a vulnerability
Email ask@nablax.in with the subject line Security. You will get a human reply, we will not pursue anyone acting in good faith, and we will tell you what we changed.
Contact
Questions about this document, or about your data: ask@nablax.in. You can also use the contact form.