Skip to content
StartFree Trial
Security and operations

Security you can check.

Every claim on this page names the mechanism behind it.

Code signing: both systems. The Mac build is signed with a Developer ID certificate and notarised by Apple. The Windows build is signed through Azure Trusted Signing — twice, in fact: the application first, then the installer that carries it, because signing only the outer shell would leave the installed program unsigned. Windows therefore names us as the publisher instead of calling the publisher unknown.

The backend runs on a managed service in the Frankfurt region.

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

Security questions we have not answered here: write to support@thalassa-consulting.com.

Where something does not exist yet, this page says so — including the things a competitor would leave out.

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.

The claim is not ours to make lightly, so we made it checkable: our release workflow verifies every executable with Get-AuthenticodeSignature and aborts a publication whose signature is not valid. The same block has guarded the macOS notarisation for months. An unsigned build cannot reach you, because it cannot be published.

Checksum. Every release also carries a SHA-256 checksum for each file. It stands in the public release manifest at /latest.json; the installation guide shows the one command that compares it. With a valid signature this is now the second way to check, not the only one — but it costs nothing and takes no word of ours on trust.

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 for every endpoint, with additional limits for conversations and model requests. Ask too fast and you get a refusal with a wait time instead of an answer.

Sign-in attempts have a per-minute request limit. If you are asked to wait, try again later. If you have forgotten your password, use password reset.

Promotional-code validation and redemption also have request limits. Repeated unsuccessful attempts trigger an increasing waiting period for that account; a successful validation or redemption clears it.

The limit of the method: counting happens separately in each server process. Multiple processes or instances have separate limits. 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 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.

Documents and questions

Data processing agreement. The data processing agreement under Article 28 GDPR is ready to download on the privacy page, as a PDF and as a Word document. For a counter-signed copy, write to info@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.