Security

Trust architecture for client intelligence.

Fern handles Slack messages, emails, meetings, calendar events, and client context. Our security posture is built around least privilege, tenant isolation, audited access, and a clear separation between raw processing data and durable client intelligence.

Least-privilege integrations

Fern uses OAuth and read-oriented integration access where possible. Integration copy should explain why each requested permission exists before a customer connects a source.

Tenant isolation

Customer data is scoped by organization IDs throughout the application. We are hardening direct database policies and API routes so every sensitive query is explicitly organization-scoped.

Encryption and secrets

Traffic uses TLS in transit, Supabase stores data encrypted at rest, and integration credentials are stored through WorkOS Vault rather than as plaintext application records.

AI provider posture

Fern uses enterprise AI APIs for classification and summarization. We are verifying gateway-level data retention terms and adding provider-specific no-training/zero-retention controls wherever supported.

Raw data minimization roadmap

The architecture direction is an encrypted, short-lived processing buffer plus a processing ledger. Persistent product value should live in structured intelligence, not raw unrelated conversations.

Deletion and support access

Admins can disconnect integrations and request deletion today. Self-serve deletion, export, retention controls, support access grants, and audit logs are part of the active trust roadmap.

Important: Fern does not claim WhatsApp-style end-to-end encryption because cloud AI processing needs temporary access to raw content. The goal is encrypted, access-restricted, short-lived raw processing and durable structured intelligence.