Security

Last updated 20 October 2026 · Tolla, operated by Dmitrii Russu, 8006 Zürich, Switzerland

Tolla handles data about your users and a read-only key to your Stripe account. This page describes how it is protected, in plain terms, and what we do not claim. Everything here describes what the service does today.

In short

• Hosted in Frankfurt, Germany, on Vercel and Neon, whose infrastructure is SOC 2 Type 2 and ISO 27001 certified.
• Emails, IP addresses and device ids are stored only as salted hashes; card numbers and prompt content never reach us.
• Each workspace's data is separated and checked on every request, and automated tests check this on every change to the code.
• Measuring never changes what your users see. A change you turn on applies only to the people it names, and if Tolla is unreachable the request goes through as today, so an outage cannot break your product.

Infrastructure

These certifications belong to our providers and cover their infrastructure, not Tolla itself. The full list, including how transfers are safeguarded, is on the Subprocessors page.

Encryption

• In transit: every connection to the website, app, API and database uses TLS.
• At rest: the database is encrypted with AES-256 by our database provider.
• Stripe keys: the restricted key you connect is additionally encrypted by Tolla with AES-256-GCM, using a key that is kept outside the database.

What we store, and what we never receive

• Identity signals (email address, IP address and network, device id, optional device fingerprint) are hashed with SHA-256 and a secret salt unique to your workspace before they are stored. The original values are never written to the database. The hashes are still personal data and we treat them as such.
• Payments come from Stripe through a read-only key with six read permissions. We store Stripe's card fingerprints, never card numbers.
• AI usage is recorded as model, token counts, cost and feature. Prompts, completions and files are never sent to Tolla; the optional content signals accept only hashes computed on your side.
• The debugging event log shows identity values masked, and is deleted after 30 days.

Access and authentication

• Accounts: an account opens only once its email address is confirmed through an emailed link, and sign-up answers the same way whether or not an address already has an account. Passwords follow NIST SP 800-63B-4: at least 15 characters, up to 128, no rules about character types, and no forced changes. A password found in a known data breach is refused: we check it against Have I Been Pwned's Pwned Passwords by sending only the first five characters of its SHA-1 hash, never the password or your email. If that service doesn't answer within three seconds, we accept the password rather than hold up your sign-up. Passwords are hashed with scrypt. Sessions use HTTP-only cookies and expire after 30 days. Sign-in, sign-up, email confirmation and password reset are rate limited per address and per account (the counters keep only keyed hashes, never addresses), and resetting a password signs out every other session.
• The API is rate limited per key, and per visitor address for browser calls; repeated attempts with unknown keys are blocked.
• Secret API keys are shown once, stored only as a SHA-256 hash and can be revoked at any time. Requests that use a secret key from a browser are refused.
• Publishable keys for the browser snippet can only send device signals and product events, can be limited to your own websites, and by default require each user id to be signed by your server (HMAC-SHA256), so nobody can send data in your users' names.
• Stripe is connected with a restricted key you create with read permissions only. Tolla refuses full-access secret keys, checks when you connect that each read permission it needs is there, and its code only ever reads. Stripe does not let anyone see whether a restricted key also has write permissions, so give it the read permissions the setup steps list and nothing more: then the key cannot charge, refund or change anything.

Separation between customers

Every record belongs to one workspace, and every page, action and API call checks the workspace before reading or writing. Identity signals and links are computed per workspace and are never used to recognise people across customers. Automated tests that try to reach another workspace's data, use keys beyond their scope or forge signatures run on every change to the code, together with tests of user deletion and retention.

Shadow mode and reliability

Measuring with Tolla only observes. It never blocks requests or changes what your users see. Our SDKs send events in the background, never throw errors into your code, and retry with backoff when the network fails.

A change you turn on in Tolla (for example a limit on free usage) applies only to the people it names, and a control group keeps today's experience. The SDK asks Tolla for at most 400 ms before a request; if Tolla is slow or unreachable, the request goes through unchanged. An outage at Tolla cannot break your product.

Retention and deletion

• Identity session data is deleted automatically after the retention period you set (30 to 730 days, 180 by default).
• You can delete everything about one of your users at any time with DELETE /api/v1/users/{userId}.
• You can delete your workspace yourself in Settings → Workspace: everything in it is deleted at once, and your account too if it was your last workspace. If you want an export first, write to dmitrii@russu.net; we send it before deleting.

Incidents

If a security incident affects your data, we tell you without undue delay and at the latest within 48 hours, with what happened, what is affected and what we are doing. Every incident is documented. The commitments are in the Data Processing Agreement.

Reporting a vulnerability

If you find a security problem, please write to dmitrii@russu.net with the details and steps to reproduce. We reply within three working days, keep you informed while we fix it, and do not take legal action against good-faith research that avoids privacy violations, data destruction and service disruption, and gives us reasonable time to fix the problem before publishing. Our security.txt has the same contact.

What we do not claim

Tolla is a young, one-person company, and we prefer to say so:

• Tolla itself is not SOC 2 or ISO 27001 certified. The certifications above are our providers'.
• Tolla has not yet had an independent penetration test.
• Tolla is not designed for health data (HIPAA), and must not receive it.

If your security review needs more, such as a completed questionnaire, write to dmitrii@russu.net.