An assistant that reads your mail has to earn the privilege. This page describes — factually, in the present tense — how the Service protects your data today. No roadmap promises, just what's built and running.
The architecture is the security model
Ask Nell is designed so that the most sensitive things — your account credentials and OAuth tokens — are structurally out of the AI's reach.
- The AI never sees credentials. The assistant works with your content (mail, calendar, notes). When it needs to act — send an approved email, create an event — it asks the application layer, which holds the tokens and performs the authenticated call. There is no code path that puts a token in front of the model.
- Approval before send. Outbound email is queued as a draft for your review. Nothing leaves without your approval or a standing instruction you created yourself.
- Email content is treated as data, never as instructions. Synced email is sanitised on the way in, and the assistant is explicitly instructed that email content can't tell it what to do — a structural defence against prompt-injection attacks hidden in incoming mail.
Encryption and secret handling
- Encryption at rest for secrets. OAuth tokens and API credentials are encrypted in the database with Fernet symmetric encryption (AES-128-CBC with HMAC authentication). There is no plaintext secret storage anywhere in the system.
- Passwords are never stored. Only salted, one-way hashes are kept.
- Transport encryption. All traffic between your browser and the Service is encrypted with TLS (HTTPS), with HSTS enabled.
- Payment isolation. Card details are handled entirely by Stripe; we never see or store full card numbers.
Tenancy and isolation
- Per-user vaults. Each account's synced content lives in its own isolated vault. Every file access is resolved and jailed inside your vault directory — path traversal out of it is a hard error, enforced in code and covered by tests.
- Scoped OAuth. We request the minimum scopes each feature needs, and we document every scope and why it's needed. Signing in with Google or Microsoft uses identity-only scopes — authentication never implies mailbox access.
Account security
- Two-factor authentication (TOTP) with single-use backup codes, available in Settings → Security.
- Device sessions. Every signed-in browser appears in Settings → Security, and you can sign out any device remotely. Password resets revoke all sessions.
- Login protection. Repeated failed logins lock the account temporarily and notify you by email. Registration is protected against automated abuse.
- Email verification for new accounts and for address changes — a new address takes over only once it's proven.
Application hardening
- Security headers across the app:
X-Frame-Options: DENY,X-Content-Type-Options: nosniff, HSTS, and a Content-Security-Policy. - CSRF protection on every state-changing request.
- Rate limiting on authentication endpoints and the API.
- Webhooks (billing) are signature-verified and idempotent.
- SSRF-guarded outbound fetches for the assistant's web tools.
Your controls
- Export everything. Settings → Security builds a complete ZIP export of your data with a 24-hour download link.
- Delete everything. Account deletion with a 30-day grace period, after which data is permanently purged — see Data Retention & Deletion.
- Disconnect any time. Removing a connection in Settings deletes its stored tokens; you can also revoke access from your Google or Microsoft account security pages.
Reporting a vulnerability
If you believe you've found a security issue, please email hello@asknell.io with the details. We read every report, act quickly on genuine issues, and will credit you if you'd like. Please don't test against other people's accounts or data.
Related reading
- Privacy Policy — what we collect and who processes it
- Data Retention & Deletion — lifecycles and the grace period
- FAQ — quick answers on security and data handling