Security Standards

Last updated: July 13, 2026

1. Encryption at Rest & In Transit

We understand that your business email inbox contains highly sensitive operations. We guard this data using rigorous encryption standards:

AES-256 Key Encryption: All Google OAuth access tokens, refresh tokens, and raw email database columns are fully encrypted at rest using military-grade AES-256 encryption. Stolen database dumps are completely useless to an attacker without the decryption key.
TLS/SSL in Transit: All data transmitted between your browser, our API backend, Google's APIs, and OpenRouter AI nodes is strictly routed via TLS 1.3/HTTPS protocols.

2. Token Guardian (OAuth Anti-hijack Loop)

To eliminate potential 401 unauthorized credential loops, our background worker utilizes our custom "Token Guardian" logic. The backend immediately and securely persists refreshed OAuth tokens straight back to the encrypted database after every successful Gmail api call, ensuring session stability and avoiding credential hijack risks.

Restricted Scopes and Data Minimization

We strictly adhere to the principle of data minimization:

We only request permissions necessary to deliver our strategic tools (reading priority mail, calendar syncing, and responding to leads). We never perform autonomous background emailing; all outbound messages are composed and sent purely under direct user instruction.
We do not store your emails indefinitely. All processed email text is automatically and permanently deleted from our database after 30 days (except for validated Revenue Signals and Meetings which you choose to sync).

Requested OAuth Scopes

openid / userinfo.email / userinfo.profile: Identity and basic profile.

gmail.modify: Read inbox, create/send drafts, manage labels and trash. One scope in place of gmail.readonly / gmail.compose / gmail.send. No autonomous sending, no permanent deletion.

calendar.readonly / calendar.events: Read and create calendar events for briefings.

contacts.readonly / tasks.readonly: Read contacts and tasks for CRM enrichment and briefings.

3. Infrastructure Sandboxing

Our servers operate under strict compliance criteria to prevent physical and remote server breaches:

Non-Root Containers: All Docker containers (frontend, API backend, and Celery workers) run under dedicated, sandboxed appuser system logins rather than root.
Secure VPC & Firewalls: Database instances run inside a private sub-network isolated from the public internet. Access is restricted exclusively to container-internal network brokers.

4. Reporting a Security Issue

We run a proactive bug-bounty and security audit program. If you discover a vulnerability or security concern in our systems, please report it immediately to our operations leads at [email protected].

Testing scope, safe-harbor terms, and our coordinated-disclosure commitments are set out in full in our Vulnerability Disclosure Policy (opens in a new tab). A machine-readable contact pointer is published at /.well-known/security.txt.