Mailbox access exposes highly sensitive communications, so secure design starts with least privilege and continues through token custody, tenant isolation, content minimization, audit, incident response, and deletion.
Separate read, modify, draft, and send permissions. Explain each scope before consent and reauthorize deliberately when the product expands; never acquire broad mailbox access for hypothetical future features.
Encrypt refresh tokens or protocol credentials with managed keys, limit decryption to connector workers, redact logs, and rotate credentials atomically. Browsers and analytics systems must never receive long-lived provider secrets.
Store metadata first, hydrate bodies only when required, scan and stream attachments safely, and enforce retention and deletion as background jobs with evidence. Google's restricted Gmail scopes can add verification and security-assessment duties.
Record account ownership, requesting principal, permission decision, provider action, and result without copying message content into audit logs. Alert on unusual access, repeated auth failures, cross-tenant checks, and volume changes.
No. OAuth controls provider authorization, but the application still needs tenant isolation, token encryption, product permissions, secure logging, retention, monitoring, and incident response.
No. Log identifiers, sizes, states, and diagnostic codes. Message content and tokens should be excluded or tightly redacted from logs and traces.
Not yet. Gmail, Microsoft Graph, and IMAP/SMTP connectors are planned. This guide documents the intended architecture and the provider requirements a production release must satisfy.
DewEngine is in development. Real use cases decide what ships first.