Why InboxBriefs only has read-only access

When you connect your inbox to InboxBriefs, you grant read-only access through the provider's official authorization flow. The key point is the scope requested: InboxBriefs asks only to read. That scope determines, at the infrastructure level, everything the app is able to do.

Read-only, guaranteed by Google, not by our promise

The distinction matters: it's not that InboxBriefs “chooses not to” change your emails. It's that read-only access doesn't give it the ability to. The provider's servers reject any attempt to send, delete, archive or modify. Even if our code tried, it doesn't, the API would return a permission error.

• Read the metadata and content needed for analysis: yes
• Send an email on your behalf: technically impossible
• Delete or archive an email: technically impossible
• Edit, label or move an email: technically impossible

Your access tokens are encrypted at rest

OAuth authorization takes the form of access tokens. These tokens are never stored in plain text: they're encrypted at the application level with AES-256-GCM before being saved. In practice, even direct access to the database would reveal only ciphertext, useless without the encryption key, which lives outside the database.

We don't keep your emails

InboxBriefs reads the emails needed to produce a summary, then keeps the summary, not the full content of your inbox, permanently. Your inbox stays the source of truth; our data is just an analysis layer on top, kept to the strict minimum.

You can revoke everything in one move

Disconnecting an inbox from your dashboard immediately revokes our access on the provider's side, the token becomes unusable that very instant. And if you delete your InboxBriefs account, all associated data is erased permanently and in cascade within minutes. A question about security or how your data is handled? Write to us at privacy@inboxbriefs.com, we reply directly, no automated form.