Security and data protection at Lovaetes BI
Last updated: September 2026.
This page describes the controls that are implemented in Lovaetes BI today, written for IT and security reviewers. It is maintained by the Lovaetes BI team and is not a third-party certification. For a Data Processing Agreement, a security questionnaire, or an architecture review, contact support@lumenbi.app or use our quote request form.
1. Data connections
The Lovaetes BI application is served over HTTPS with HTTP Strict Transport Security, and requests to supported cloud sources (Google Sheets, Microsoft 365 / OneDrive and SharePoint, Airtable, and REST endpoints) are made over HTTPS. Outbound requests pass through a server-side URL guard that validates every hop, blocks private and link-local network targets, strips credentials from redirects, and caps response size.
For direct Postgres and MySQL connections, Lovaetes BI requires TLS: the connection is opened with encryption enabled and a configuration that disables TLS (sslmode=disable, ssl=false, useSSL=0) is rejected before any query runs. We encrypt these connections; we do not perform certificate-chain verification or pinning, and we do not claim that every possible customer-side network path or self-hosted deployment is encrypted.
SQL Bridge is deployed and operated by the customer. Production SQL Bridge deployments should be published over HTTPS with a valid certificate; the bridge URL and bearer token are supplied by the customer.
2. Tenant isolation
Customer data is owned by an organization and scoped to a workspace. Access is enforced in the database with row-level security policies, so a query issued under one user's identity cannot read another tenant's rows even if an application-layer check were missed.
Server-side functions re-verify the caller's session and workspace membership before loading data, building AI context, or generating exports. Requests that carry an object identifier are checked against the caller's authorization rather than trusted, so a guessed or copied identifier does not grant access. Demonstration content is restricted to platform accounts and is not visible to customer tenants.
3. Files and generated artifacts
Spreadsheet and CSV uploads are parsed in your browser. The raw upload bytes are not stored on our servers; what is persisted is the extracted, structured rows and their metadata, written under your workspace and protected by the same row-level security as the rest of your data.
Reports, PDF exports, and PowerPoint decks are generated on demand inside authenticated requests and streamed back to the requesting user. Dynamic authenticated responses are returned with Cache-Control: private, no-store so they are not retained by shared or intermediate caches.
A dashboard or component you choose to share produces an unguessable token generated with a cryptographic random source. Token reads are rate-limited per IP address, are also served no-store, and the link can be revoked at any time from the product.
4. Connector credentials
Connector credentials — database passwords, API keys, bridge bearer tokens, and OAuth material — are sealed with AES-256-GCM envelope encryption before they are written to the database. Decryption happens only inside server-side handlers at the moment a query runs.
Credential columns are never returned to the browser and are never placed into AI context. Database access policies deny client-side reads of the credential store, so a compromised browser session cannot retrieve stored secrets.
5. Database connectivity
Lovaetes BI does not execute user-supplied SQL against your database. The platform constructs its own read queries: SELECT statements against a chosen table with an explicit row limit. There is no code path that issues INSERT, UPDATE, DELETE, DDL, or stored-procedure execution against a customer database, and the SQL Bridge additionally rejects non-read statements on the customer side.
Oracle and SQL Server are not connected directly from our cloud runtime. They are reached through SQL Bridge, a small gateway you host inside your own network, so those database credentials never leave your environment.
We recommend creating a dedicated, least-privilege, read-only database identity for Lovaetes BI, limited to the schemas and tables you intend to analyze.
6. AI data handling
Before any AI feature loads business context, the server verifies that the caller is authorized for the requested workspace, and the context it assembles is restricted to that workspace. Results the AI produces — analyses, KPIs, dashboards, insights — are persisted under the same tenant scope and the same row-level security policies.
Actions suggested by the assistant are proposals. Creating, changing, or deleting anything is re-authorized server-side against the acting user before it takes effect.
Prompts and the context sent with them are processed by the configured AI provider. Retention and model-training terms are governed by that provider's agreement and the configuration in force for your deployment; review the provider terms as part of your assessment. We do not make a blanket no-training claim on this page.
7. Access and accountability
Authenticated application surfaces require a valid session. Deliberately shared dashboards use revocable, cryptographically unguessable, rate-limited, read-only links. Access inside an organization is governed by roles (owner, admin, editor, viewer), and platform administration is a separate server-verified role: the Admin route is gated before it loads and again on every privileged server call, not only in the interface.
Sensitive operations — organization join-code lookups, shared-link reads, AI actions — are rate-limited server-side. Security-relevant events such as connector connect, disconnect, and credential rotation, share-link creation and revocation, and data-source deletion are recorded with the acting user and a non-secret description of the change. This event record is a security log for these specific actions; it is not an immutable ledger and it does not cover every action in the product.
8. Infrastructure and verification
Lovaetes BI runs on Supabase (managed Postgres, authentication, storage) and Cloudflare (edge delivery and the application runtime). A current list is maintained on our Subprocessors page.
On the public web, the application is served over HTTPS with HSTS and a set of security response headers including a content security policy, frame and MIME-type protections, and a restrictive referrer policy. Controls that are configured in a provider's own console are their responsibility under their terms; we describe them here as used, not as independently verified by us.
Current assurance status
- Technical controls: implemented and continuously tested as part of our automated test suite and release checks.
- Formal certifications: Lovaetes BI does not currently claim SOC 2 or ISO 27001 certification.
- Enterprise reviews: security questionnaires and architecture reviews are handled through our existing contact and quote request path.
Incident response and disclosure
If we become aware of a security incident affecting your data, we will investigate, mitigate, and notify affected customers without undue delay and in line with applicable data protection law. Notices go to the email on file for workspace owners and admins.
Report suspected vulnerabilities to support@lumenbi.app. We acknowledge within two business days and will work with you on a remediation timeline. Please do not disclose issues publicly before we have had a reasonable opportunity to fix them.
What customers are responsible for
Security is shared. You are responsible for protecting your account credentials, managing workspace roles and removing access when people leave, scoping connector credentials to least privilege, deciding which data is appropriate to connect or upload, securing your own SQL Bridge deployment, controlling who receives shared links, and reviewing AI output before acting on it.