Trust
Security
OptiSight Global reads data a customer would not want another customer to see: who uses which software, what it costs, and when it renews. This page describes the controls that protect it as they are implemented today, and lists what is not implemented yet.
Last updated 20 September 2026
1Tenant isolation
Every customer is an organization, and every row of imported data carries the organization it belongs to. Access is enforced by Row Level Security in the database: each read and write runs as the signed-in user, and the database itself refuses rows that user is not a member of. Isolation is not a filter the application remembers to apply; it is a rule the database applies whether the application remembers or not.
The application holds no service-role key, so a defect in application code cannot reach another tenant’s data — the credential that would allow it does not exist in the deployment. The few database functions that run outside Row Level Security take no tenant argument: each resolves the tenant itself, from the signed-in user or from a collector’s credential.
The tenant an action applies to is resolved from the signed-in session on the server. It is never taken from the browser, a form field or a URL.
2Encryption
Data is encrypted in transit with TLS on every connection, and at rest by the managed services the product runs on: the database and file storage are hosted on Supabase, the application on Vercel. OptiSight relies on those providers’ encryption at rest and does not operate its own key management.
3Authentication and invitations
Production sign-in is email and password through Supabase Auth, with email confirmation before first use and a two-step confirmation page so that a mail scanner opening a link cannot spend it. Password changes send a notice to the account’s address.
Workspace invitations are single-use links that expire. The database stores only a hash of the invitation token, never the token itself, so a copy of the database does not yield a working invitation.
An evaluation mode exists for trying the product against synthetic data with no account. It is refused outright on the production deployment.
4Least privilege for background work
Large imports are written by a background worker after the uploading request has ended. It runs as a dedicated database role with permission to execute a fixed, documented set of functions and no privilege over any table. None of those functions accepts an organization as an argument, so the worker has no way to address a tenant other than the one whose import it holds. It checks its own privileges at start-up and refuses to run if they have grown.
The worker holds no storage credential of its own. It receives a signed URL scoped to one uploaded file, valid for a limited time.
5Secrets and source control
Developer machines run a secret scanner on every commit they make, and the repository’s continuous-integration workflow scans the full history on every change it checks. Push protection — refusing a secret before it reaches a branch — is not in place; it is listed in section 7. Server-side secrets — the worker’s database credential, the scheduler secret, AI provider keys — are never exposed to the browser, and shared secrets are compared in constant time.
Every page is served with a Content-Security-Policy that admits scripts only by a per-response nonce, refuses framing, and confines connections to the application and its database. A script injected into a page does not carry the nonce and does not run.
6The AI layer
Ask OptiSight phrases figures the deterministic engine has already computed. The model receives assembled facts, never the database, and is not called when there is no evidence for a question. No prompt, question or answer is stored by OptiSight. Where the provider supports it, requests are sent with retention disabled; where it does not, retention follows the provider’s account policy and the deployment’s choice of provider reflects that.
7Not yet implemented
The following are known gaps. They are stated here so that a reviewer does not have to discover them.
- No third-party security certification or attestation (for example SOC 2 or ISO 27001).
- No independent penetration test has been performed.
- No audit log of who viewed what.
- No push protection on the repository: a secret can reach a branch before the continuous-integration history scan reports it. GitHub’s own scanning is not available on the repository’s plan.
- No single sign-on, SCIM provisioning or enforced multi-factor authentication.
- Rate limiting on the public pilot form is per instance, not shared.
8Reporting a vulnerability
Write to security@optisightglobal.com. The address reaches a person, not a ticket system, and is also published at /.well-known/security.txt. Please do not open a public issue for a security report. Security questionnaires and vendor assessments go to the same address.
This page describes controls as implemented on 20 September 2026. It is not a certification and does not assert compliance with any standard.