There is nothing from your meeting to leak

Thalassa stores no recording, no transcript and no screenshot. Not for a retention period, not “temporarily for quality” — the data is discarded once the answer is on screen.

This is an architectural statement, not a promise about staff discipline: an employee with full database access would find no meeting content, because none is written. Your own documents never reach us at all — the knowledge base lives in a folder on your machine and is searched there.

What we do hold is account data: your email address, your plan, your usage. That is needed for billing and support and cannot be defined away. The privacy policy sets out which data that is and on what legal basis we hold it.

Encryption

In transit. The application, the assistant window and the website speak to the backend over HTTPS only. There is no unencrypted fallback path if something fails. Connections to the model providers and to speech recognition are encrypted as well.

At rest. The account database is encrypted at the storage layer. It sits in a private network segment and is not reachable from the internet — only the backend can reach it. Knowing the address does not help; there is no route in from outside.

The exception we would rather name ourselves. Your knowledge-base documents sit on your device, in your user folder. They are protected exactly as well as the rest of your machine is — by its disk encryption, if you have it on (FileVault on macOS, BitLocker on Windows). We do not encrypt them a second time. If other people can reach your unlocked machine, they can reach those files.

What encryption does not do. It protects data on the wire and on the disk. It does not protect against someone using your password. That is what the next section is for.

The application on your machine

No provider keys inside it. The application holds no credentials for Anthropic, AWS, Deepgram or DeepL. It asks the backend; the backend talks to the providers. Take the installed application apart and there is nothing in it worth extracting.

The rights it asks for — and no others:

• Microphone — for your own voice; asked at your first conversation.
• Screen recording (macOS) — for screen analysis; without it the feature stays off, and it is asked only when you use it.
• System audio (macOS) — for the other party’s voice; a one-time setup.
• Network — for fetching answers; always.

No administrator rights in normal operation. No background service that keeps running after you close the app. No access to files other than the ones you put into the knowledge base yourself.

Code signing: not yet. The application is not currently signed with a developer certificate, so Windows and macOS warn about an unknown publisher on first launch. That warning says nothing about the contents of the file — it says a paid certificate is not in place. Both certificates are planned; the Apple one is in progress. The download page carries this notice today, and it will disappear when it stops being true, not before.

Checksum. Every release has a published checksum on the download page. Comparing it tells you the file you downloaded is the file we shipped. That is not a substitute for a signature, but it is something you can verify without taking our word for anything.

Accounts and sign-in

Passwords are never stored in clear text. What is stored is a PBKDF2 hash with a random per-account salt and 200,000 iterations. Your password cannot be recovered from it — we could not send it to you if we wanted to, because we do not know it. Someone who steals the database gets a list of hashes whose reversal costs 200,000 operations per password guess.

The per-account salt means two people with the same password get different stored values, so one precomputed table cannot be used against every account at once. The comparison runs in constant time, so a wrong password takes exactly as long to reject as a right one takes to accept — otherwise the response time alone would tell an attacker how many characters were correct.

Sessions. Signing in returns a short-lived signed token (30 minutes by default). The signing key stays on the server and never leaves it. When the token expires the application signs in again; you normally do not notice.

Signing in with Google means you have no password with us at all. What protects the account is then whatever protects your Google account, including any two-factor setup there.

Two-factor authentication for Thalassa’s own passwords does not exist yet. If your security policy requires it, sign in with Google — or talk to us before you buy.

Keys to your other systems

Connecting Thalassa to Google, Microsoft 365 or a CRM creates an access token to your account there. Such a token is a bearer instrument: whoever holds it reaches your mailbox or your CRM without a password and without a second factor. It is therefore not treated like an ordinary database field.

• The token is encrypted with AES-256-GCM before it reaches the database. The column holds a sealed envelope, not a readable value.
• The envelope is bound to your account and to that provider. An envelope copied out of the database cannot be replayed against another account — decryption fails rather than quietly returning something wrong.
• There is a keyring, not a key. The first entry encrypts new values; every entry can still read old ones. A key can therefore be rotated without breaking existing connections and without downtime.
• That keyring is separate from the token-signing key used for sign-in, so rotating sign-in keys does not render every CRM connection unreadable.
• Without a valid keyring, connections are switched off in production rather than stored unencrypted as a fallback.

You can disconnect any integration at any time. The envelope is deleted and the access is handed back to the provider.

Abuse protection

Rate limiting counts requests in a sliding window: per client address for every endpoint, and additionally per account for the expensive ones — conversations and model requests. Ask too fast and you get a refusal with a wait time instead of an answer.

A growing lockout covers what rate limiting alone does not: password guessing. Someone patient enough stays under any per-minute threshold. So the wait grows with each consecutive failed attempt — from nothing, through seconds, to several minutes — and drops back to zero on the first success. A person who mistypes once notices nothing; a program working through a list comes to a halt.

Promotional-code redemption is rate-limited too, per account and per address. Guessing codes is otherwise a business model.

The limit of the method: counting happens per server instance, so with several instances it applies per instance. This explicitly does not apply to consumption — minutes and quotas are booked in the database under a lock and stay exact even under parallel requests.

When a provider fails

After several consecutive failures a model is bypassed for about a minute rather than retried. After that the circuit breaker lets exactly one probe request through: if it succeeds, everything is normal again; if it fails, the bypass stays. A recovering provider is not immediately hit with full load again.

Most of the time you notice nothing — there are four model tiers, and one being out does not affect the others. In the worse case you get a message saying no answer is possible right now. What you do not get is a quietly worse answer from a different source.

One documented exception: live translation. If the translation service fails, the language model takes over — and the application tells you it switched. That is a different processor handling your data, which makes it a privacy statement rather than a convenience question.

Availability — what is and is not promised

There is no contractual availability commitment. No percentage, no service credits, not even as an estimate. A stated availability figure is a contractual obligation with a measurement method, a reporting path and a legal consequence. Putting one on a website without all of that is either meaningless marketing or a liability entered into by accident.

What actually holds:

• The backend runs on a managed service in the Frankfurt region.
• The database is backed up by the provider.
• There is no second region and no automatic failover. If Frankfurt is out, the service is out.
• There is no public status page today.

During an outage the application tells you the backend is unreachable instead of silently failing to answer. What runs locally keeps running: searching your own documents does not need the backend. New answers do.

For Enterprise, an availability commitment is negotiable — but it exists only once it is in a contract.

How updates reach you

Three delivery paths that do not touch each other: the website, the backend, and the desktop applications. Each can be updated without the others. A typo on the website is fixed in minutes without restarting the backend and without anyone downloading anything; a backend fault does not take the website down.

Applications are built per operating system — a Mac builds the Mac releases, a Windows machine the Windows one — so one platform is occasionally available a few hours before the other.

Prices exist in three places: the website, the backend and the account page. An automated test compares all three and fails if they drift apart. That is not a detail — a price that reads differently in one place is, in a dispute, the price the customer saw.

Backend updates are invisible to you; a running conversation may reload once. Your knowledge base and settings are stored separately from the installation and survive updates.

Measurement data

There is a voluntary, off-by-default transmission of technical measurements — response times, error categories. No content.

It is built as an allow-list, not a deny-list. The obvious design would be a list in the app of things never to send: no transcript, no question, no document names. A deny-list is only as good as its completeness, and a new field nobody thought about slips through. The server does it the other way round: only what is explicitly named is accepted, and anything unknown is discarded rather than forwarded. Even a faulty application cannot leak content this way — so “your documents stay on your device” holds without having to trust the program on your device.

Every text value is length-limited and, where a fixed set of options exists, must match one of them. Free text has no way in.

It applies only to signed-in accounts, only when switched on explicitly, and only when enabled server-side. The account identifier is turned into a stable pseudonym that cannot be reversed without a server-side secret, so measurements can be correlated without an email address appearing in the analysis.

Incidents and how to report one

If personal data is breached, the GDPR deadlines apply: notification to the supervisory authority within 72 hours, and notification of affected people where the risk is high.

The competent supervisory authority is the Hungarian data protection authority (NAIH), because Thalassa Consulting Kft. is based in Budapest. You can also always contact the authority where you live or work.

What a breach could actually involve. Meeting content is not stored, so a breach could concern account data — email address, plan, usage — and, in the worst case, stored access tokens for connected systems. That is exactly why those tokens are separately encrypted and bound to their account: a database dump alone is not enough to use them.

What you should do, independently of what we do: revoke Thalassa’s connections in your CRM or Google account, and change your password. Both work without us and take effect immediately.

Found a vulnerability? Write to the address in the imprint. We do not treat such reports as an attack.

What we do not have

This is the section other vendors leave out. Every line here is a real gap, not a modest way of describing something we do have.

• No code signing certificate. Your operating system warns on first launch; verify the published checksum instead.
• No two-factor authentication for our own passwords. Use Google sign-in if your policy requires two-factor.
• No ISO 27001 and no SOC 2 certification. Neither certification exists here, so please do not expect a report against either standard.
• No security.txt and no bug bounty. Report vulnerabilities to the address in the imprint.
• No public status page. Outages are visible in the application, not on a status page.
• No availability commitment (SLA). There is none outside a negotiated Enterprise contract.
• No written access-control and role policy. Access is limited by company size, not by a document.
• No written incident runbook. The GDPR deadlines apply; the internal sequence is not yet written down.
• No second region and no automatic failover. A Frankfurt outage is a full outage.

We would rather you read this list here than discover it during procurement. If one of these blocks a purchase, say so — several are on the roadmap, and knowing which one matters changes the order they get built in.

Data processing agreement. A data processing agreement under Article 28 GDPR is not published on this page, but it is available on request: write to info@thalassa-consulting.com and you will get the current version.

Security questions we have not answered here: write to support@thalassa-consulting.com. The privacy policy names the processors and the legal bases, help answers the everyday questions, and the glossary explains the terms used on this page.