Your data, guarded by default.

Tenant isolation

Every dashboard, dataset, AI prompt, and automation is bound to a tenant ID at the database level. Cross-tenant queries are rejected by the data access layer before they reach storage. There is no “break-glass” path that lets one customer see another customer’s rows — not from the app, not from the AI, not from the support tooling.

• Per-tenant identity carried in every request, validated on every query
• Tenant boundary enforced in the query engine (DuckDB) and the metric runtime
• AI Agents receive only the tenant’s slice of the semantic layer in their prompt
• Background jobs (imports, refreshes, exports) carry tenant ID through the queue

Row- and column-level security

Define data access policies once and have them enforced everywhere — SQL queries, dashboard widgets, AI Ask Agent answers, and exports. RLS rules can reference user attributes, group membership, or tenant context. CLS hides sensitive columns at the schema layer; the AI never sees a value it shouldn’t suggest.

• Row-level filters applied at query time, transparent to the user
• Column-level masking for PII (email, phone, SSN-style fields auto-detected)
• AI prompts include only the columns the requesting user can see
• Audit log records every access decision, every override

Identity, SSO, and access

• Single sign-on via SAML 2.0 and OpenID Connect on the Business and Enterprise tiers
• Just-in-time provisioning and group-to-role mapping from the IdP
• Native MFA for non-SSO users (TOTP and email codes)
• Granular roles: Owner, Admin, Editor, Viewer · per-resource overrides on dashboards and datasets
• Session, API-key, and webhook-secret rotation without losing audit history

Encryption & key management

• In transit: TLS 1.2+ everywhere — app, API, connectors, and the load balancer
• At rest: AES-256 on Cloud SQL, GCS, and the Redis cache
• Application secrets: Fernet-encrypted (32-byte key) and stored in Google Secret Manager
• Backups: daily, encrypted, retained 30 days; point-in-time recovery on Cloud SQL

Network & platform

LumenQube runs on Google Cloud, region us-central1 (additional regions on Enterprise plans). The architecture is locked down with private networking and a managed WAF.

• Cloud Run backend with INTERNAL_LOAD_BALANCER ingress — no public IPs on services
• Cloud Armor WAF in front of the load balancer with the OWASP Core Rule Set + per-IP rate limits
• Cloud SQL on a private IP behind a VPC connector
• HTTPS-only with HSTS, X-Frame-Options DENY, strict CSP, and Permissions-Policy headers on every response
• Hidden admin portal with IP allowlist + MFA for platform operators

AI safety

The AI surface is the highest-risk vector for data leaks. We treat it that way.

• Prompts are constructed server-side from the governed semantic layer — the model never sees raw rows it isn’t supposed to
• RLS / CLS policies are applied before any query runs against the AI’s suggestion
• Every Agent run is logged with tier (Haiku/Sonnet/Opus), token counts, dollar cost, and the user it ran for
• Validate-then-save means an AI-generated widget or automation is type-checked and simulated before it can persist
• Hard quotas on AI tokens prevent runaway costs from a misconfigured loop

Compliance

We are pursuing the certifications buyers actually ask for. Status is honest: in progress means “we are doing the work and our timeline is real,” not “we are ready except we don’t have the audit.”

Logging, audit, and incident response

• Tamper-evident audit log of every authentication, permission change, dataset access, and AI run
• Application logs, request logs, and Cloud Audit logs centralized in GCP Logging with 30-day retention (longer on request)
• 24/7 on-call rotation for severity-1 issues; status communicated to all paying customers
• Vulnerability disclosures: please email security@lumenqube.com. We acknowledge within 1 business day.