Security

Our approach

Genlobe is a multi-tenant Backend-as-a-Service: our customers (we call them Tenants) build their own applications on top of the platform, and each application lives as an Organization with its own data namespace. This page describes the technical and organizational measures we have in place to protect the data entrusted to us.

We describe only what is actually running in production today. Where a capability is planned but not yet implemented, we say so explicitly — see What we're still improving below. This transparency is deliberate: we would rather under-promise than over-declare controls we do not have.

Encryption

In transit. All traffic between clients and the platform, and between the platform and its infrastructure and AI-model providers, travels over encrypted connections (TLS / HTTPS). We do not serve any endpoint over plain HTTP.

At rest. We never store credentials in plaintext:

• Passwords are hashed with bcrypt (automatic per-password salting).
• Configuration and integration secrets — for example, each Organization's own Stripe keys under the bring-your-own-key model — are encrypted with Fernet (authenticated symmetric encryption). The configuration tables store only the opaque ciphertext.
• API keys are stored as HMAC-SHA256 hashes — never the raw value — and verified with constant-time comparison.

The underlying database is provided by our managed Postgres provider (see Infrastructure & sub-processors).

Access control & data isolation

Separation between Organizations is structural, not a decision left to the frontend:

• Role-based access control (RBAC) governs every operation, with distinct roles for Tenant members and explicit elevated-role checks for administrative actions.
• Strict per-Organization isolation. The Organization identifier is mandatory end-to-end on every data access path. A missing value raises an error rather than silently falling back to a wider scope — there is no shared, tenant-wide namespace to fall into.
• Row-level scope. Records created by a standard end-user are scoped to their author: an end-user only sees the records they created, unless an explicitly authorized elevated role accesses them.
• Secrets are never returned. Secret values are never exposed in API responses — to a client or to an AI agent.

Authentication & secrets

• JWT-based sessions for user authentication, with optional Google OAuth sign-in.
• Scoped API keys for programmatic access, hashed at rest and bound to a single Organization — a key scoped to one Organization cannot reach another (cross-Organization access returns "not found", never the data).
• Rate limiting on authentication endpoints to slow down brute-force and abuse.
• Operations that need to set a secret use a redirect flow to an administrative screen where a human enters the secret manually — the secret never travels through an AI agent's tool input and is never echoed back.

Audit logging

We maintain append-only audit logs for sensitive operations:

• Platform administrative actions — who (actor), what action, on which resource, when, and the source IP.
• Per-Organization billing events — actor, role, action, and before/after state.

By design, secrets, API keys, and webhook secrets are never written into these logs.

Payment security (PCI DSS SAQ-A)

Genlobe does not process, transmit, or store payment-card data. All payment flows are delegated to Stripe's hosted checkout; card data never touches Genlobe's servers. As a result, our PCI DSS scope is limited to SAQ-A.

Infrastructure & sub-processors

The platform runs on AWS (us-east-1) — Elastic Beanstalk for compute, Amplify for the web frontends, and SES for transactional email — with the production database hosted on Supabase (managed Postgres). Payments are handled by Stripe, AI traffic is routed through OpenRouter (and the upstream model providers it routes to), and social login uses Google OAuth.

The complete, maintained list of sub-processors — including each provider's service and transfer safeguard — is published on our sub-processors page.

Backups & resilience

Backups are managed by our database provider and include point-in-time recovery, so the production database can be restored to a chosen moment within the provider's retention window.

We are honest about the limit here: today, backups live within the managed database provider. A separate, off-site, immutable backup is not yet in place — see below.

Responsible disclosure

If you discover a security vulnerability in Genlobe, we ask that you report it responsibly and privately, without exploiting it or disclosing it publicly until we have had a chance to remediate it.

• Security contact: security@genlobe.ai
• What to include: a description of the vulnerability, the steps to reproduce it, and the potential impact.
• Our commitment: we will acknowledge your report and work in good faith to assess and fix it.

We do not run a formal bug-bounty program yet, but we genuinely welcome and value reports.

What we're still improving

In keeping with our principle of not over-declaring, these are controls we are actively working toward but do not yet have:

• Automated breach and anomaly detection. We do not yet have an automated system for detecting anomalous authentication, bulk exfiltration, or privilege escalation; monitoring today is largely manual and provider-level.
• Off-site, immutable backups. An independent backup outside the managed database provider is planned but not yet implemented; in the meantime we rely on the provider's point-in-time recovery described above.
• Hardened session storage. Session tokens currently live in the browser's localStorage; a move to httpOnly cookies is planned.