Security at Lagible

1. OAuth scopes we request

We request three Google OAuth scopes. Every scope is justified below in plain language. We do not request scopes we do not use. We do not request scopes “just in case”. If you find a scope being requested that is not listed here, that is a bug and we want to know.

The canonical scope list lives in src/lib/google/oauth.ts (variable GMAIL_SCOPES). The Domain-Wide-Delegation path used by Google Workspace tenants requests the same four scopes; the Workspace admin grants Lagible's service account the same trust set rather than per-user OAuth consent.

2. Why gmail.modify and not gmail.readonly

Google grades sensitive Gmail scopes into two tiers for OAuth verification. Restricted scopes (gmail.readonly, gmail.full) trigger Google's CASA Tier 3 assessment, which is an annual penetration test plus full secure-development-lifecycle review. Sensitive scopes (gmail.modify, gmail.compose, gmail.send) trigger CASA Tier 2, which is an annual security questionnaire plus targeted controls review.

Lagible needs to apply user-created labels (Pinned, Done, Snoozed) so that classifying a thread in our chat UI is mirrored back to the user's Gmail account. That mirroring requires a write capability, which makes gmail.readonly insufficient. We chose gmail.modify because it grants exactly the writes we need (label apply / remove) without the broader powers gmail.full grants (permanent deletion, sending, account settings).

We do send mail, but only when you press the inline Reply button. Every send is user-initiated. Nothing sends on a schedule, in the background, in bulk, or in response to anything other than your explicit click. The body and recipient are exactly what you typed. gmail.send is declared up front in the consent screen so this capability is visible at the moment you grant access, not hidden inside the implicit send permission that gmail.modify would otherwise grant on its own.

Both gmail.modify and gmail.send are Sensitive scopes (CASA Tier 2). Neither escalates us to Tier 3 (Restricted), which would apply only if we requested gmail.readonly, gmail.full, or mail.google.com. Lagible never requests any of those.

3. Google verification and CASA assessment status

4. Encryption and key handling

Every Google OAuth refresh token in our database is encrypted with AES-256-GCM. The encryption key is a 256-bit secret held only in our hosting provider's environment variable store (Vercel Encrypted Environment Variables). It is never written to disk, never committed to git, never sent to a client browser, never returned by any API endpoint, and never logged.

All transport uses TLS 1.2 or higher. HSTS is enforced. Authentication cookies are httpOnly, secure, and sameSite=lax. Database access from the application runs under Postgres Row Level Security, scoped by the authenticated user's identity. The Supabase Service Role key never ships in any client bundle (CI guards against it on every deploy).

Key rotation: we rotate the master encryption key annually or immediately on suspected compromise. Rotation is dual-write (decrypt with old, encrypt with new) so we never lose access to live grants during the cutover.

5. Retention schedule

This table is the source of truth for what we store and for how long. The Privacy Policy references this table by ID. If the two ever disagree, this table wins.

24-hour cancellation purge: when you delete your Lagible account or disconnect an inbox, we purge all message bodies, metadata, AI outputs, and OAuth tokens from the live database within 24 hours. Backups containing residual copies cycle out within 30 days. You will receive an email confirmation when the live-database purge completes.

6. Incident response

Named contact: ayushopchauhan@gmail.com. This inbox is monitored by the founder during business hours (India Standard Time) and pages a secondary contact for high-severity reports outside hours.

• Acknowledgement: within 24 hours of receipt for any confirmed report.
• Customer notification of personal data breach: within 72 hours of becoming aware of a breach affecting personal data, per GDPR Article 33. Notification includes the categories and approximate number of data subjects, categories of records, likely consequences, and measures taken or proposed.
• Authority notification: where required by applicable law, we notify the relevant supervisory authority within the statutory window (72 hours under GDPR).
• Post-incident report: a public post-mortem published within 30 days of resolution for incidents affecting customer data, with the named root cause, timeline, and remediation.
• Affected customers: receive a dedicated technical brief within 7 days of resolution detailing what was exposed, what was not exposed, and the remediation timeline.

7. Audit log retention

We log every authentication event, every billing event, every settings change, every admin action, every inbox connect / disconnect, every account-deletion request, every data-export request, every fail-open of the subscription gate. Logs include timestamp, user ID (hashed where required by GDPR), event type, and outcome.

Log retention is 24 months on rolling rotation. Access to raw logs is restricted to the founder and any on-call engineer named in the runbook. Customer-facing audit log access (your own events only) is available via the data subject access request process described in the Privacy Policy.

8. SOC 2 commitment

We are committed to SOC 2 Type 1 followed by Type 2 attestation. Today we are pre-audit, and we are publishing the timeline here so the commitment is in writing.

Named auditor placeholder: engagement letter signed but auditor name not yet public for engagement confidentiality. The auditor will be a top-50 firm by accepted SOC 2 attestation volume. Email ayushopchauhan@gmail.com for the executed engagement letter under NDA.

9. Responsible disclosure

We accept security reports at ayushopchauhan@gmail.com. PGP key available on request. We commit to:

• Acknowledgement within 24 hours.
• Triage decision within 5 business days.
• Fix in production within 30 days for high-severity, 90 days for medium.
• Public disclosure window: 90 days after the fix ships, or sooner with coordinated disclosure.
• No legal action against good-faith researchers who follow this process and do not access or modify other customers' data.

Out of scope for disclosure: denial-of-service attacks, social engineering of staff, physical attacks on infrastructure, third-party services we depend on (report to that vendor directly).

10. Subprocessors

Lagible relies on the following subprocessors. The list here is the canonical source. The Privacy Policy and the Data Processing Addendum reference it. We notify customers in writing 30 days before adding a new subprocessor (announcement on this page plus email to billing contact on file).

See the Data Processing Addendum for the legal terms governing each subprocessor relationship.

Related

• Privacy Policy: data categories, lawful basis, your rights, cookie notice, controller identity.
• Terms of Service: acceptable use, limitation of liability, governing law, dispute resolution.
• Data Processing Addendum: Article 28 obligations, subprocessor list, breach notification timeline.