Privacy Notice
Version 1.0 · Effective and last updated: 4 August 2026
This Privacy Notice explains how Assertum Ltd. collects and uses personal data when you visit our website, create or use an Assertum account, use the local MCP/CLI, delete an account, or contact support.
1. Who is responsible for your data
Assertum Ltd., a company registered in the Republic of Cyprus, is the controller of the personal data described in this Notice. Privacy contact: support@assertum.ai.
2. The important local-only boundary
Assertum is a QA-automation service that exposes a local MCP/CLI interface. Your UI trees, interactions, prompts, screenshots, source code, generated tests and other test content remain on your device. Assertum does not receive or store that underlying test content or raw test structure.
The CLI creates a deterministic, per-user keyed fingerprint of test structure and sends the fingerprint to Assertum. The fingerprint is not the underlying structure. We use it only to detect duplicates and protect quota integrity within your account, and we do not compare it across users.
The CLI also sends only the limited event properties listed in section 4. It does not create or send an installation ID, device ID or local analytics ID.
If you connect the local MCP/CLI to an AI provider, agent, MCP server or other third-party service, that provider may receive information according to your configuration. You select and control that connection. The third party’s own privacy terms apply; Assertum does not become responsible for the third party merely because you connect it.
3. Where we get personal data
We receive data:
- from Google when you choose Google Sign-In and authorise Google to share your basic profile;
- from you when you use the Service, choose account settings, submit optional deletion feedback or contact support;
- automatically from the authenticated Service when it records quota usage and the limited first-party events below; and
- from our own account systems when they create session, entitlement, lifecycle and deletion records.
We do not buy personal data from data brokers.
4. What we process, why, and our lawful basis
Article references below are to the EU General Data Protection Regulation (GDPR).
| Data | Purpose | Lawful basis |
|---|---|---|
| Google profile: email address, name, profile-picture URL, provider=google, Google provider ID, and account creation/update/deletion timestamps | Create, authenticate and administer your account and provide the Service | Article 6(1)(b): contract or steps requested before contract |
| Authentication records: SHA-256 refresh-token hash, expiry and revocation status; short-lived OAuth/CSRF state | Maintain sign-in and session integrity and protect the Service; we do not store the raw refresh token in the database | Article 6(1)(b) for authentication and Article 6(1)(f) for security and abuse prevention |
| Plan and entitlement records: tariff, status, company/seat identifier, feature overrides and subscription lifecycle timestamps | Supply and administer the selected plan and features, including the initial free plan | Article 6(1)(b) |
| Quota usage: tests-created count and last-test-created timestamp | Apply and show your account quota | Article 6(1)(b) |
| First-party events: user ID, test_saved or account_resurrected, platform/source, step count, whether a prompt was provided, and scenario-file kind | Operate, understand and improve the Service and investigate quota or account abuse | Article 6(1)(f): reliable operation, product improvement and abuse prevention |
| Per-user keyed test-structure fingerprint created locally by the CLI | Detect duplicates and protect quota integrity within your account; it is not compared across users | Article 6(1)(f): fair quota operation and abuse prevention |
| Deletion ledger: separate server-side keyed hashes of email and Google provider ID, key ID, quota used at deletion, account age, reason and provider | Prevent repeated registration from resetting free quota and investigate account abuse | Article 6(1)(f): maintaining a fair free-service quota |
| Optional deletion reason and free-text comment | Receive voluntary exit feedback and improve the product | Article 6(1)(a): your consent; leaving the fields empty has no effect on deletion |
| Support correspondence | Respond to your request, provide support, protect and defend the Service, and comply with applicable duties | Article 6(1)(b), 6(1)(f) or 6(1)(c), depending on the request |
| Error reports: the logged message, stack trace, build release and environment, and any internal identifier the code attached to the message, such as the internal account ID | Detect, diagnose and fix failures and keep the Service secure and available | Article 6(1)(f): our legitimate interest in a reliable and secure service |
| Database backups of the records above | Restore availability and integrity after an incident | The basis applying to each backed-up record, together with Article 6(1)(f) for resilience and security |
The event data and fingerprint are first-party telemetry stored in Assertum’s PostgreSQL database on Hetzner in Germany. We do not use an external analytics vendor.
We do not use IP addresses, user-agent strings, device identifiers, request contents, crash reports or CLI command content as product-analytics fields. Error reports exist to keep the Service working; they are handled separately from the product events above and are not combined with them.
5. The two keyed-hash systems
The Service uses two different systems. They are not combined.
Per-user test-structure fingerprint
The backend derives or issues a stable key for your account through an authenticated session. The CLI uses that per-user key to create the deterministic test-structure fingerprint locally. Backend master or derivation material is kept outside PostgreSQL; test-fingerprint key material is not stored in PostgreSQL. Key versioning supports rotation. We compare the resulting fingerprint only within your account for duplicate and quota controls.
Deletion-ledger hashes
When an account is deleted, the server separately creates keyed hashes of the email address and Google provider ID. The server-side key is kept outside PostgreSQL; the ledger row stores only its key ID. These hashes help recognise re-registration for 24 months so that deleting and recreating an account does not reset the free quota.
Because Assertum retains the means to compare the deletion-ledger hashes when the same identifier is presented again, we treat them as pseudonymous personal data, not anonymous data.
6. Legitimate interests and your objection right
We have documented assessments for processing based on Article 6(1)(f). The main safeguards are limited event fields, local handling of test content, within-account-only fingerprint comparison, separate keys, restricted retention, no advertising use, and a right to object.
You may object at any time by emailing support@assertum.ai. Tell us which processing concerns you and why. We will stop the processing unless we demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or the processing is needed for legal claims. An objection to quota-integrity processing may affect whether we can continue providing a free account, but we will assess the particular request rather than treating that result as automatic.
7. Cookies and local CLI storage
Our website uses HTTP-only access_token and refresh_token cookies strictly to authenticate your session. The CLI stores only the authentication credential or token cache and user configuration needed for the local Service. We do not use advertising, behavioural-tracking or analytics cookies, and the CLI does not store an installation/device or local analytics identifier.
See the Cookie and Local Storage Notice for details.
8. Who receives personal data
Access is limited to people and providers who need the data for the purposes above:
- Assertum personnel and authorised contractors, subject to confidentiality and access controls;
- Hetzner, which hosts the application and PostgreSQL database in Germany as our infrastructure processor;
- Google Sign-In, where Google processes the Google-account side under Google’s own terms and privacy notice and acts as an independent controller for that activity; once Assertum receives your basic profile, Assertum controls its use for the Assertum account;
- Google Workspace, which processes support-email customer content for Assertum under the Google Cloud Data Processing Addendum;
- Sentry, which receives server-side error reports and their technical context as our error monitoring processor; and
- courts, regulators, law-enforcement bodies, professional advisers or transaction counterparties where disclosure is required by law or reasonably necessary to establish, exercise or defend legal claims, protect rights and security, or complete a genuine corporate transaction with suitable safeguards.
Our Service Providers Notice gives more detail. User-selected AI providers, agents and MCP servers are not Assertum subprocessors for your local test content.
9. International transfers
The Assertum application and PostgreSQL database are hosted in Germany.
Google Workspace may use global infrastructure and subprocessors. Where a transfer of Workspace customer personal data is restricted under applicable data-protection law, the Google Cloud Data Processing Addendum provides the applicable alternative transfer solution or incorporates the European Commission’s Standard Contractual Clauses, together with the safeguards described there.
Google Sign-In is a service you use under your Google account terms. The applicable Google entity and any Google-account transfers depend on your location and Google’s relationship with you. Assertum’s own receipt and further use of your profile are governed by this Notice.
Sentry, our error-monitoring provider, may process data outside the European Economic Area; restricted transfers rely on the European Commission’s Standard Contractual Clauses or another valid safeguard.
If we appoint another provider or make a new restricted transfer, we will use a valid safeguard and update our disclosures where required.
10. How long we keep data
| Data | Retention |
|---|---|
| Account/profile, quota and entitlement data | While your account exists; removed from the live database when the account is deleted |
| First-party product events | Kept after account deletion, carrying only the internal account identifier of the deleted account, which no longer resolves to a live account; retained while useful for reliability and product work |
| Database backups | Overwritten within 30 days |
| Session/security records | Until expiry or revocation, then deleted within 30 days |
| Deletion ledger, including keyed email/provider-ID hashes and quota at deletion | 24 months after account deletion |
| Optional exit-survey reason and comment | 12 months after submission |
| Support correspondence in Google Workspace | Three years after the last contact |
| OAuth/CSRF state | Automatically deleted after expiry |
| Error reports held by our error-monitoring provider | Kept only as long as needed to diagnose and fix failures |
We may retain a specific record longer if required by law, a binding order, or a documented legal claim. If so, we restrict it to that purpose and remove it when the need ends.
11. Account deletion
Account deletion is a hard deletion from the live account tables. It removes your profile, authentication, entitlement and quota records from the live database.
First-party product event records are stored separately and are not deleted with the account. They carry the internal account identifier of the deleted account and the limited event properties listed in section 4 — no email address, name or Google provider ID — and once the account is gone that identifier no longer resolves to a live account. You may ask us to delete these records as well; see section 13.
Backups are not used as an active data source and are overwritten within 30 days. If recovery from a backup is required during that period, deletion controls must be reapplied before restored data returns to ordinary use.
The limited deletion-ledger row described above remains for 24 months. It has no foreign-key link to the deleted user account and contains no raw email address or raw Google provider ID, but its keyed hashes remain pseudonymous personal data.
Deletion feedback is optional. Do not enter personal data, confidential test information, source code, credentials or other sensitive material in the free-text comment.
12. Security
We use technical and organisational measures designed to protect personal data in view of the nature and risks of the processing. These include limited data collection, access controls, hashed refresh tokens, separation of keyed-hash secrets from PostgreSQL, encrypted transport where supported, provider contracts, backups and incident procedures.
No online service can guarantee absolute security. You should secure your Google account, devices, local credential storage and any third-party service you connect.
13. Your data-protection rights
Depending on applicable law, you may have the right to:
- obtain information about our processing and access your personal data;
- correct inaccurate or incomplete data;
- request deletion;
- restrict processing;
- receive data you provided in a structured, commonly used and machine-readable format and transmit it elsewhere where portability applies;
- object to processing based on legitimate interests;
- withdraw consent for optional exit feedback at any time, without affecting earlier lawful processing; and
- complain to a supervisory authority.
To exercise a right, email support@assertum.ai. We may request information reasonably necessary to verify identity and protect the account. We normally respond within one month, subject to lawful extensions for complex or numerous requests. Rights can have legal limits; if we cannot fulfil a request, we will explain why and tell you about available complaint routes.
You may complain to the Office of the Commissioner for Personal Data Protection, Republic of Cyprus. If you live elsewhere, you may also be entitled to contact your local data-protection authority.
14. Automated decisions
Quota counters and the within-account fingerprint may automatically identify duplicate use and apply the account’s free quota. Assertum does not use this processing to make a decision that produces legal effects or similarly significant effects about you within the meaning of GDPR Article 22. If you think a quota result is wrong, contact support and we will review it.
15. Users under 18
Assertum is not specifically directed at children. A person under 18 may use the Service only with the permission and supervision described in the Terms. We do not intentionally collect age or date of birth. If you believe a child is using the Service without appropriate authority, contact us so that we can investigate and take appropriate action.
16. Worldwide users
The English-language Service is generally accessible worldwide, but version 1.0 does not actively target the United Kingdom or specific non-English-language markets. If local law gives you additional mandatory privacy rights, this Notice does not remove them.
Assertum does not sell personal data, share it for cross-context behavioural advertising, or use it for targeted advertising. We do not offer a financial incentive in exchange for personal data. Users in the United States may use the contact method in section 13 for access, correction, deletion or objection requests; we will apply any mandatory state right that covers the request.
17. Changes to this Notice
We may update this Notice when our processing, providers or legal duties change. We will publish the new version and effective date. If a change materially affects your privacy, we will provide reasonable additional notice, such as an in-product or email notice, where required.
18. Contact
For privacy questions or requests: Assertum Ltd., a company registered in the Republic of Cyprus. Email: support@assertum.ai.