Security

workwae is operated by WORKWAE LLC and is in early access. This page describes the controls built into the service today. The Privacy Policy is the binding statement of what we collect, use, share and delete; where this page and the policy differ, the policy applies.

Encryption

In transit

All traffic between your application, workwae and the providers is encrypted with TLS. Plaintext logins to IMAP and SMTP servers are refused.

At rest

Secrets and content are sealed by the application before they are written to the database or object storage:

• OAuth access and refresh tokens, IMAP, SMTP, CalDAV and CardDAV passwords, customers' own OAuth app secrets, Zoom and Webex grants, webhook signing secrets, queued outgoing messages, stored message bodies, raw messages and attachments, cached contact photos, and data exports.
• Each value is encrypted with AES-256-GCM under a data key that is wrapped by a transit key held in HashiCorp Vault. The key never leaves Vault; the application authenticates to it with its own credentials.
• The encryption is bound to its context: the tenant, the purpose (a credential, a webhook secret, mail content and so on) and, for grants and app secrets, the record it belongs to. A value copied to another tenant, field or record fails authentication and cannot be opened.
• Data keys are scoped to one tenant and purpose. Stored objects are sealed in 64 KiB chunks, each authenticated on its own, so a tampered, truncated or reordered file is rejected.
• The mail search index holds a search vector of stored message text, never the text itself.
• Console passwords are stored only as salted hashes, and API keys only as hashes.

Key rotation

The Vault transit key can be rotated at any time without downtime: new data keys are wrapped with the new key version at once, and a background pass then rewraps every sealed value and stored object onto it. Older key versions are retired only after every database backup taken before the rewrap has aged out, so restores keep working.

Access to provider data

An account is connected only when its owner, or an administrator of their organization, approves the provider's consent screen. workwae never sees Google, Microsoft, Zoom or Webex passwords. The full list of permissions and what each is used for is in the Privacy Policy.

Least privilege

• Calendar, contacts and shared-mailbox permissions are requested only when the connection uses those features; a plan without them asks for none.
• For Gmail, the platform app requests gmail.modify, which cannot permanently delete mail, and never the full https://mail.google.com/ scope.
• Zoom and Webex access covers scheduling the meetings attached to calendar events and identifying the host. workwae does not access recordings, chat, transcripts or participant lists.

Google

Microsoft, Zoom and Webex

Microsoft data is accessed through Microsoft Graph or Exchange Online and used only to provide the service (details). Zoom and Webex data is limited to the connected user's identity and the meetings workwae creates (Zoom, Webex).

Revoking access

• Deleting a Google account in workwae revokes its grant with Google, retried through a Google outage for up to a day, unless another connection of the same Google account through the same app still uses it.
• Disconnecting Zoom revokes the grant with Zoom and deletes the stored tokens immediately. When a user removes workwae in the Zoom App Marketplace, Zoom notifies us and every grant that user gave workwae's Zoom app is deleted at once.
• Users can also remove access from the provider's own settings at any time; the links are on our support page.

People

workwae staff do not read connected account data except in the limited cases listed in the Privacy Policy, such as a support request you ask us to look into. Access to production systems is limited to authorized personnel who need it to operate the service.

Tenants, roles and API keys

Tenant isolation

Every customer is a separate tenant. Its accounts, messages, events, contacts, webhooks and keys are scoped to it, its stored objects live under its own prefix, and its sealed values are encrypted under its own data keys and bound to it, so they cannot be opened as another tenant's.

Console roles

Console members are owners, admins, members or viewers, and the role is enforced on every console action. Invitations and role changes never grant ownership; it moves only by transfer.

API keys and account tokens

• API keys carry scopes (read, write, send, admin), are shown once when created and stored only as hashes, record when they were last used, and can be revoked at any time.
• Account tokens give a client access to a single connected account and expire after the lifetime they were issued with.
• Rate limits apply per tenant and per key, so one key over its limit never blocks the tenant's other keys.

Audit log

Every request that changes something is recorded in the tenant's audit log, without secrets or message content, and kept for 365 days. Workspace admins and owners can read it in the console or through the API.

Safeguards in the API

• Signed webhooks. Every delivery is signed per the Standard Webhooks specification so your endpoint can verify it came from workwae (verifying signatures). New endpoints must use HTTPS.
• No requests into private networks. Webhook deliveries and mail server connections refuse private and loopback addresses. A webhook's host is resolved once and the connection pinned to the checked addresses, so DNS rebinding cannot redirect it, and redirects are never followed.
• Connect flows. After sign-in, users are sent back only to redirect URIs on the tenant's allowlist. A sign-in is bound to the browser that started it, so a callback opened anywhere else connects nothing.
• Tracking links. Open, click and unsubscribe links carry signed tokens that can only lead where the sender wrote; unsubscribe links do not contain the recipient's address.

Infrastructure and backups

• Location. Data is stored and processed on servers in the United States. Cloudflare delivers our sites and provides DNS and DDoS protection.
• Database. PostgreSQL. The application connects with a role that can read and write data but cannot change the schema; migrations run separately as the owner.
• Backups. The database's write-ahead log is archived continuously with WAL-G (at least once a minute), with nightly base backups. Backups are compressed and encrypted before they leave the database host, and the host itself cannot delete earlier versions of them. Point-in-time restore reaches back at least 21 days; backups are kept for up to 35 days. Vault is snapshotted hourly.
• Restores. The restore procedure is covered by an automated drill that archives, restores and verifies a database end to end.
• Monitoring. Metrics, logs and traces are collected in our own observability stack, with alerts on stalled syncs, webhook and send backlogs, encryption and key-rotation errors, and backup failures. Our monitoring reads ids, statuses, counts and timestamps, never subjects, bodies or correspondents' addresses.

Data lifecycle

Default retention periods, consistent with the Privacy Policy:

Customers can export a whole workspace or a single account, and delete accounts or the workspace, from the console or the API. Exports are stored encrypted until they expire.

AI features

AI features (reply classification and draft writing) are off until a customer turns them on. When on, workwae sends only the text a feature needs, such as a reply's subject and the start of its text, to Gatewae, the AI gateway we use, which forwards it to a language model provider. We use only providers that do not train on the data we send, and we never use it to train any model. What is sent for each feature is listed in the Privacy Policy.

Subprocessors

Service providers that process data for us under contract and only on our instructions:

The full list, with what each provider receives and where, is at workwae.com/subprocessors. New subprocessors are announced 30 days ahead, as set out in our Data Processing Addendum.

Reporting a vulnerability

Email security@workwae.com with a description of the issue and the steps to reproduce it. Our contact details are also published at /.well-known/security.txt.

We welcome reports from researchers acting in good faith. When testing, please:

• use only accounts and data you own or have permission to use;
• stop and tell us if you reach anyone else's data, and do not keep, share or change it;
• avoid anything that degrades the service, such as load testing or sending spam; and
• give us a reasonable chance to fix the issue before you disclose it publicly.

We will acknowledge your report and keep you updated until it is resolved. If we learn of a breach affecting your information, we will notify affected customers and, where required, end users and authorities.