Email Security

Encrypted vault. Searchable cache.
Zero plaintext at rest.

Per-tenant envelope encryption with KMS-wrapped keys, OAuth-scoped access with minimal permissions, and cryptographic verification on every inbound delivery. Your email data is locked down at every layer.

Visual Assist (Co-browse) Live Chat Security Email (Shared Inbox)

Message encryption

Envelope encryption. Per-tenant keys. Zero plaintext at rest.

Every email body is encrypted before storage using a per-tenant data encryption key (DEK) wrapped by a cloud KMS. The primary database never holds plaintext message content.

Per-tenant keys

KMS-wrapped DEKs

Each organization gets its own data encryption key. The DEK is stored encrypted (wrapped) — only the KMS can unwrap it at runtime.

AES-256-GCM

Unique IV per message

Every message is encrypted with a cryptographically random 12-byte IV. Authenticated encryption — tampered ciphertext fails decryption.

Separated layers

Ciphertext + search split

The database of record stores only ciphertext. A separate, isolated search index enables full-text queries without exposing the primary store.

Key rotation

Zero-downtime

Old and new DEKs coexist via versioning. Rotation generates a new key without re-encrypting existing messages.

OAuth & token security

Scoped access. Encrypted tokens. Instant revocation.

Gmail integration requests the mailbox scope required for SMTP-based shared inbox delivery. Refresh tokens are encrypted at rest and rotated automatically.

SMTP-capable scope

mail.google.com

Gmail requires the full mail scope for SMTP XOAUTH2. Helpr uses it only for connected inbox sync, send, labels, and per-recipient delivery.

Token encryption

AES-256-GCM

Refresh tokens are encrypted at rest with AES-256-GCM before storage. Plaintext tokens never persist.

Auto-rotation

Refresh cycle

When Google issues a new refresh token, helpr replaces the old one atomically. No stale credentials linger.

Per-inbox revocation

Instant disconnect

Tokens are revocable per-inbox. Disconnecting a Gmail account immediately invalidates all stored credentials.

Inbound security

Verified delivery. Sanitized HTML. Remote images controlled.

Inbound email is delivered via authenticated push notifications. Every delivery is cryptographically verified before processing, and email content is sanitized before storage.

Cryptographic verification

RS256 signature validation on every inbound delivery
Issuer and audience claims verified on each request
Expired or malformed tokens rejected immediately
Replay protection via monotonic history tracking

Content sanitization

Scripts and event handlers stripped from HTML
Dangerous protocols (javascript:, data:) removed
External images blocked to prevent tracking pixel IP leaks
Quoted text stripped before encrypted storage

Access controls

Per-inbox permissions. Role-based visibility.

Email inboxes support granular access controls so agents only see the conversations they should. Visibility is enforced at every layer — API, WebSocket, and UI.

Per-inbox agent access: organization, team, or restricted
Inbox member roles control who can configure vs. reply
Sidebar visibility scoped to assigned inboxes only
Conversation assignment limits visibility to assigned agents
Admin override for full inbox access when needed
Access changes take effect immediately across all sessions

Inbox membership

Agents must be explicitly added to an inbox before they can see its conversations. No default access — everything is opt-in.

Visibility tiers

Three access levels — org (everyone), team (team members), and restricted (explicit members only) — control who sees each inbox in the sidebar and search results.

Data lifecycle

Soft delete. Grace period. Hard purge.

Deleted email data follows a controlled lifecycle. Nothing disappears instantly and nothing lingers forever. Cascade rules ensure orphaned data is cleaned up.

Soft delete with 60-day grace period for recovery
Search index purged immediately on deletion
Ciphertext permanently removed after grace period
Inbox deletion cascades to all conversations and messages
Attachments cleaned up with parent messages
Audit trail preserved with redacted identifiers post-deletion

Soft delete

Deleted conversations are flagged but retained for 60 days. During this window, accidental deletions can be recovered by support. The search index is purged immediately to prevent search hits.

Hard purge

After the 60-day grace period, a scheduled job permanently removes all ciphertext. No residual data remains — encrypted content, IVs, and key references are all destroyed.

More security deep dives

Every product. Every layer. Documented.

Each helpr product has its own security architecture. Explore how Live Chat handles session tokens and encryption, or how Visual Assist achieves zero-knowledge co-browsing.

Live Chat security Visual Assist security

FAQ

Frequently asked questions.

Are email bodies encrypted?

Yes. Every email body is encrypted with AES-256-GCM using a per-tenant data encryption key (DEK) before storage. The DEK itself is wrapped by a cloud KMS and never stored in plaintext. There is zero readable email content in the database at rest.

What Gmail permissions does helpr request?

Helpr requests the Gmail https://mail.google.com/ scope because Gmail SMTP XOAUTH2 requires it for per-recipient outbound delivery. We use it only for the connected inbox: sync, send, labels, and delivery tracking. We do not request contacts access or access outside the connected mailbox workflow.

Can helpr read my entire mailbox?

No. helpr only processes new messages that arrive after the account is connected. Historical messages are not bulk-imported. The integration watches for new inbound mail and processes it on arrival — it does not crawl or index your existing mailbox.

What happens if I disconnect an email account?

Disconnecting an account immediately revokes the stored OAuth tokens and stops inbound sync. Existing conversations remain in helpr (encrypted) but no new messages will be synced. You can optionally delete all associated conversations, which triggers the soft-delete lifecycle.

Is the search index encrypted?

Yes. The search cluster uses encryption at rest and encryption in transit (TLS). It runs in an isolated private network with no public access. Access is restricted to application servers only.

How are OAuth tokens protected?

OAuth refresh tokens are encrypted with AES-256-GCM before storage — the same envelope encryption model used for message bodies. Tokens are automatically rotated when Google issues replacements, and they can be revoked instantly per-inbox by disconnecting the account.

Encrypted vault. Searchable cache.Zero plaintext at rest.