← Ataski · Trust & security · DPA · Subprocessors

This is the canonical English version. Native translations for DE / ES / FR / PT / RU are pending counsel sign-off.

Approved 2026-10-08

Cryptography and Key Management Policy

Owner: the founder. Approved: 2026-10-08. Review: annually, and on any significant change — a new key, a new place a key is kept, a new algorithm, or an incident that touches a key.

Scope: every cryptographic mechanism that protects Customer Data or access to it, and the keys behind each one. Where each credential lives and when it is due is docs/security/secrets.md; how to replace one is docs/runbooks/secret-rotation.md. This page states the rules and the limits.

1. Rules

No home-made cryptography. TLS is Caddy's, at-rest encryption is the storage provider's, application-layer encryption is the cryptography library's Fernet, and tokens are signed with standard HMAC constructions. New code uses SHA-256 or stronger for any new hash or signature.
Nothing is served to a person over plain HTTP. HTTP redirects to HTTPS, and HSTS tells the browser not to try again.
A key lives in exactly one of the places secrets.md §1 names — never in git, a log line, a template, a model prompt, an issue or a chat.
Customer credentials are encrypted before they are written and are never included in any export, the customer's own included.
A key is replaced on suspicion of exposure, on a departure, on a vendor advisory, and otherwise on the yearly schedule in secrets.md §3. A rotation is finished only when the old value is revoked.

2. What is in use today

What is protected	Mechanism	Who holds the key
Browser and webhook traffic to `ataski.com` and `api.ataski.com`	TLS 1.2 minimum, TLS 1.3 preferred (Caddy defaults); Let's Encrypt certificates issued and renewed automatically; HSTS for two years including subdomains (the preload directive is sent; the domain is not on the browsers' preload list)	Certificate private keys in Caddy's data volume on the application server
Application to Neon Postgres	TLS, required by the connection string	Neon; database credentials in the production environment configuration
Application to Cloudflare R2 and to every sub-processor API	HTTPS to the vendor's endpoint	Each vendor; API credentials in the production environment configuration
Database at rest, including point-in-time history	AES-256, by Neon	Neon — Ataski holds no key
Files at rest (uploads, generated PDFs, transcripts)	AES-256, by Cloudflare R2	Cloudflare — Ataski holds no key
Connected-account credentials (OAuth tokens, API keys, mailbox passwords, customer-supplied Anthropic keys, webhook secrets)	Fernet (AES-128-CBC with HMAC-SHA256) in the application, before the row is written; the columns are classified secret and never exported	One application key in the production environment configuration — see §4
The keyed lookup hash of an accounting company id	HMAC-SHA256 under a subkey derived from the credential key with HKDF-SHA256	Derived at run time; not stored
Sign-in sessions	WorkOS sealed session cookie, `__Host-` prefixed, `Secure`, `HttpOnly`	The WorkOS session-sealing key, in the production environment configuration
Signed links and tokens (OAuth `state`, CSRF, unsubscribe and consent links, share links, add-in and MCP tokens)	HS256 JWTs, or `itsdangerous` signatures	The application signing key, in the production environment configuration

3. Where keys live and who can reach them

Production: the production environment configuration on the application host, read at start-up. It is not in git. Only the founder can reach it, over key-only SSH.
Development: the founder's workstation, which is treated as production infrastructure under the Acceptable Use Policy.
Provider-held keys (Neon, Cloudflare R2, WorkOS, Stripe and the other sub-processors): held and rotated by the provider under its own security programme. Ataski cannot read them.
People: the founder is the only person who can read any key. There is no secrets manager yet (access-control.md §8).

4. Rotation

Procedure: docs/runbooks/secret-rotation.md — mint new, deploy it, verify the path that uses it, revoke the old, record it in the internal rotation ledger.
TLS certificates rotate themselves: Caddy renews each Let's Encrypt certificate well before its 90-day expiry.
Application signing key: rotating it signs every user out and invalidates every outstanding add-in and MCP token. Done in a quiet hour.
Credential key: a dedicated key for stored customer credentials, separate from session sealing, with rotation that keeps reading data encrypted under the previous key while it is re-encrypted under the new one, is being introduced.

5. Not in place today

No HSM or cloud KMS. Keys are held in the production environment configuration.
No per-tenant keys or envelope encryption. One application key protects every workspace's stored credentials.
No customer-managed keys (BYOK / HYOK) for data encryption. A customer may supply its own Anthropic API key; that is a model-provider credential, not an encryption key.
Further hardening of the application host and its internal connections is planned. The specific items, their owner and their target dates are tracked in Ataski's internal risk register, which is available to customers under NDA on request to security@ataski.com.