Security Overview

Last updated: June 28, 2026  ·  LeadWithEmail (Love Ellie Inc.)

This is a factual summary of how LeadWithEmail is built today. We describe what is implemented and are explicit about current limitations rather than overstating our posture.

1. Authentication

Sign-in is handled by Clerk using Google as the sign-in provider. We do not store passwords. Sessions are carried by a Clerk-issued session cookie, and the server verifies each request’s session token (RS256, validated against Clerk’s public keys) before granting access to your data.

2. Tenant isolation

Each account is a separate tenant, identified by a unique tenant key. Every data query is scoped to your tenant key at the application layer, so one customer’s contacts, campaigns, emails, and tracking data are not exposed to another customer.

Limitation: isolation is currently enforced primarily in application code. Database-level Row-Level Security is in place for some tables and is being extended to the remaining ones. We treat completing this as a pre-launch hardening item.

3. Gmail OAuth tokens

We never see or store your Google password. Gmail access and refresh tokens are encrypted at rest using Fernet (AES-128-CBC with HMAC authentication); the encryption key is supplied via an environment variable held separately from the database. You can revoke access at any time (see Data Deletion), which removes the stored tokens and revokes them with Google.

4. Admin access controls

A small site-owner/admin area exists for platform operations. Access is restricted to a specific allow-list of operator accounts; any other signed-in user who attempts to reach an admin URL receives a "not found" response and cannot view admin data.

5. AI usage logging

Every AI call is recorded in an internal, append-only audit log with the account identifier, provider, exact model, purpose, feature, token counts, estimated cost, and status. This supports cost accounting and abuse prevention.

The audit log stores metadata only. It does not store prompt text, generated email bodies, or the contents of replies. The audit log is visible only to site-owner/admin operators; normal users cannot access it.

6. Transport & hosting

Traffic is served over HTTPS. The application is hosted on Railway, with data stored in a managed Supabase PostgreSQL database in the United States. See Subprocessors for the full list of services we rely on.

7. Current limitations

In the interest of honesty, the following are not yet in place:

  • Database Row-Level Security is not yet applied to every table (see Section 2).
  • We have not completed a formal third-party security audit, penetration test, or SOC 2 / ISO certification.
  • Exact data-retention windows for backups and server logs are not yet formally documented.

To report a security concern or vulnerability, email [email protected].

Last updated: June 28, 2026