01
Design stance.
The service is fail-closed. Startup, delivery, and billing paths verify their preconditions and refuse to run when a check fails. An unverified sender, an unsigned webhook, an unknown address, or an invalid offer results in refusal, not best-effort processing.
02
Access controls.
- Verified-owner access: the service acts only for the verified owner inbox.
- Single-use hashed magic links for authentication; secure host-only sessions with CSRF controls.
- Exact address binding: work is accepted only at the exact agent address provisioned for the account.
03
Data path.
- Signed provider webhooks are verified before any event is trusted.
- Tenant-scoped queries: one account cannot read another account's data.
- Content limits and malware scanning on submitted attachments.
- Encryption in transit; restricted local storage; encrypted backups.
04
Operations.
- Redacted logs: application logs must not contain message content or raw identifiers.
- Rate limits on inbound and API paths.
- Monitored recovery with 30-day standard backup windows (see Retention).
05
What the service does not access.
The initial release does not receive access to your entire mailbox, contacts, calendar, device, or CRM. You deliberately send it the threads you want it to hold. Unknown or unauthorized inbound delivery is not retrieved for content processing after the routing check fails.
06
Reporting a concern.
No method is perfectly secure. Report a security concern through the Support page and it will be reviewed promptly.