Your content is encrypted in transit and at rest, using per-organization keys wrapped by AWS KMS. We never use your content to train AI models. Our support team cannot read your content — by design, not just by policy. And we're honest about what we're not: we are not end-to-end encrypted.
Encryption
In transit
TLS 1.3 between your device and our servers. Cloudflare for DNS only — no Worker-proxy intercepts your traffic in our v1 architecture.
At rest — disk layer
The entire database is AES-256 encrypted at the storage layer by Supabase / AWS RDS.
At rest — content layer
Above the disk layer, content columns (notes, comments, reminder messages, version snapshots) are envelope-encrypted with a per-organization Data Encryption Key (DEK).
Key management
Each DEK is wrapped by a Key Encryption Key (KEK) held in AWS KMS in us-west-2. KMS audit logs every wrap and unwrap.
Why "admin can't read your content" is technical, not aspirational
Two independent controls back this claim. Either one failing does not unlock content access:
-
Database layer. Our admin database role has
REVOKE SELECTon every content column. Even if someone gained admin database access, the queries needed to read content would be rejected by Postgres. -
Cloud layer. The IAM principal used by our
admin tooling has an explicit
Denyonkms:Decryptagainst the KEK. So even with the encrypted bytes in hand, the admin cannot ask AWS to decrypt them.
Both controls live in different systems (Postgres roles vs. AWS IAM) with different change-control surfaces. Bypassing either leaves an audit trail; bypassing both leaves two.
Honest limits
We are not end-to-end encrypted. The encryption key is held server-side because we need to:
- Render public share links you create (the server has to decrypt to render HTML).
- Execute the AI actions you opt into (the model needs plaintext).
- Provide reliable cross-device sync and account recovery without losing your data when a device is wiped.
We think these tradeoffs are right for a to-do list. If E2E is a hard requirement for you, Signal and Proton Drive are better fits. We will never call ourselves "end-to-end encrypted" or "zero-knowledge" in our marketing — those are precise terms and we don't meet them.
Account security
Passwords
Hashed with bcrypt at high work factor. Compromised-password check via HaveIBeenPwned (k-anonymity prefix; full hash never sent).
Second factor (TOTP)
Time-based one-time passwords (RFC 6238) via any standard authenticator app — 1Password, Authy, Google Authenticator. No SMS factor (SIM swap risk).
Sign in with Apple / Google
Both supported as alternatives to email + password. We receive only the OAuth claims we need.
Session management
You can view active sessions in Settings → Account → Active sessions, and revoke any one of them.
AI privacy
AI is opt-in and off by default. When you enable it, the relevant text for the action you trigger — titles, notes, comments within the scope of that action — is sent directly to Anthropic's API. Attachments are never sent.
Under Anthropic's default API terms, prompts are not used to train models; they may be retained for up to 30 days for abuse monitoring. Crosstask is enrolling in Anthropic's Zero Data Retention (ZDR) program; until that enrollment is approved, the 30-day retention applies.
Crosstask does not log AI prompts beyond per-request metrics (model, token count, cost, fields sent). You can turn AI off any time in Settings → AI.
Deletion: crypto-shred
When you delete your account and the 30-day grace period expires, we don't just hide your rows — we drop the wrapped DEK that protects your content. Without the DEK, every backup, every replica, and every snapshot of your encrypted data is permanently unreadable. The math, not our policy, guarantees the deletion.
Operational security
- Production access is gated through SSO + hardware key.
- Production database queries are logged via Supabase audit logs and Postgres
pg_stat_statements. - Secrets live in Supabase dashboard secrets + edge-function runtime env. Source files containing real values are gitignored and chmod 600 on developer machines.
- Build and deploy run on GitHub-hosted runners with signed commits required on the main branch.
Subprocessors
See our Privacy Policy for the full list of subprocessors, their roles, and the regions they operate in.
Responsible disclosure
Found a security issue? Please email security@crosstask.app with a clear description and steps to reproduce. PGP key on request.
Our commitments to you:
- Acknowledgement within 2 business days.
- Initial assessment within 5 business days.
- Fix or mitigation timeline within 10 business days for high-severity findings.
- Public credit (with your consent) in our advisory once fixed.
We do not currently run a paid bug-bounty program but we appreciate good-faith research. Please test only against accounts you control, do not access or exfiltrate other users' data, and give us reasonable time to fix before public disclosure.