Open Transparency

What we collect

Health and biometric data is a special category under GDPR Art. 9 and is treated accordingly. We process only what you explicitly provide or authorise:

• Health & biometric data (lab results, DNA files, HRV, sleep, heart rate)
• Wearable & sensor data (Apple Health, Oura, Whoop — integrations not yet available)
• User-authored content (notes, goals, supplement logs, training plans)
• Identity & authentication data (email, passkey credentials, anonymised internal user ID)
• Technical metadata (access logs, consent records, processing activity logs)

Within the service, each ingested item is additionally assigned a fine-grained data category (e.g. blood samples, genetic data, lifestyle, medical history, wearable data, body composition, nutrition, mental health, medications, supplements, allergies, personal care, reproductive health, vaccinations, family history, sleep, stress, plus an admin-reviewed "other" bucket). This classification is technical — it drives the ingestion pipeline, MCP access-key scoping, and audit logging — and does not define separate consent scopes (see "Consent model" below). When you upload data of a kind the category set does not yet cover, the item is held under an AI-proposed label pending administrative review: the administrator sees only the proposed category label, never the item's content, and either maps the item to an existing category or accepts it under the proposed label.

Legal basis

• → Explicit consent (Art. 6(1)(a) and Art. 9(2)(a)) — for all health and biometric data. Consent is freely given, specific, informed, and revocable at any time — given once at account activation by confirming the Data Processing Consent as a whole.
• → Performance of contract (Art. 6(1)(b)) — for data strictly necessary to provide the service (authentication, account management).
• → Legal obligation (Art. 6(1)(c)) — for records we must keep by law (e.g. accounting records).
• → Legitimate interest (Art. 6(1)(f)) — for records kept to protect rights and legitimate interests (logs, complaint records).

Only data you explicitly upload or authorise for import is stored. It is used solely to provide the service to you. No cross-user profiling is performed on individual health data; anonymised aggregate metrics may be derived for internal service quality monitoring.

Encryption model

• → In transit: TLS 1.3 or higher on all communications — including the channel between your client and our backend.
• → Server-side envelope encryption: Your data is sent to the backend over TLS — the client does not perform the encryption. On the backend, a dedicated crypto engine encrypts each item under its own data-encryption key (DEK), then wraps that DEK with a key-encryption key (KEK) held in HashiCorp Vault (transit secrets engine). Only the wrapped DEK is stored alongside the ciphertext; the KEK never leaves Vault, and the platform never holds the plaintext key material. Plaintext exists only transiently in backend memory during processing.
• → Encrypted Envelopes throughout: No plaintext personal data is written to event streams, databases, or object storage — they carry data exclusively as encrypted envelopes. Normalised content is split into deterministic chunks, each encrypted individually under its own DEK.
• → The vector index is the honest exception: the embedding vectors in the vector database are not encrypted — semantic search wouldn't work otherwise. But the index holds only the vector plus three identifiers (a chunk reference, profile id, and data category): no text, no document content, no encryption material. Vectors are computed exclusively from normalised, PII-stripped content you approved, and the index is fully derived — it can be wiped and rebuilt from the encrypted chunks at any time, and is useless without them.
• → One root key per user: Each user has their own root key, created at account activation and held in HashiCorp Vault as a non-exportable Transit key. Every operation that touches it — wrapping and unwrapping data keys, key derivation, HMAC — is performed by Vault's Transit API inside Vault itself: our services send data in and get results back, never the key. So the root key doesn't just never leave Vault — it can't. Purpose-specific keys (data encryption, metrics pseudonymisation) are derived from it inside Vault, so compromising one derived key never exposes the others. Deleting the root key makes all of that user's encrypted data permanently unreadable (crypto-shredding) — this is how account erasure is implemented.
• → Biometric metrics are stored under a pseudonymised ID (an HMAC derived from the user's root key), decoupled from your account identity. Rotation of this pseudonymised ID is planned to further limit longitudinal re-identification.

Data locality & hosting

All user data is stored and processed on a self-hosted Kubernetes cluster at the company's premises in Brno, Czech Republic — within the European Union. No data is transferred outside the EU in the normal course of operations. AI inference runs in EU Azure regions (see section 4). The cluster currently runs on two nodes, with a third prepared but kept powered off — partial hardware redundancy, not full high availability. This arrangement is temporary by design: the target setup (multi-node or managed EU hosting) will be decided based on how the service grows during the Open Beta, and any future hosting provider will be contractually bound to EU data locality.

Sub-processors

No personal data is shared with third parties for commercial or analytical purposes. The following processors receive data under a Data Processing Agreement — this is the complete list (infrastructure is self-hosted, so no hosting provider is involved):

Data retention

Deleting your account always deletes all of your data. Audit logs (processing records, consent records, access logs) are retained independently, for the period required by law. A tiered retention model for long-lived data (daily resolution for 3 months, monthly aggregates to 1 year, yearly aggregates beyond) is designed but not yet implemented, and the handling of stored data when a paid feature is cancelled — as distinct from closing the account — will be defined before paid features are introduced.

Your GDPR rights

Consent model

• → Consent is obtained once, at account activation: you confirm the Terms of Service, Privacy Policy, and Data Processing Consent together, each as a whole. There are no per-category consent toggles.
• → Data categories are a technical classification, not consent scopes. Adding or changing a category does not require a new agreement; the agreements change only when the processing itself materially changes (e.g. a new sub-processor or the introduction of paid features), with advance notice as described in the Terms of Service and Privacy Policy.
• → Every consent event and every access to personal data is written to an immutable audit trail (timestamp, data category where applicable, stated purpose, user identifier).

You: no passwords, ever

• → Magic link is the default sign-in for every account: a single-use, short-lived token sent to your registered email, invalidated the moment it is used. No password is stored, transmitted, or required — and there is no password reset flow to attack.
• → Passkeys (FIDO2/WebAuthn) are supported and encouraged. Once you register one, it becomes your primary login and the magic-link fallback is no longer offered by default. Passkey credentials are stored in the Methos account database and never leave our trust boundary; all WebAuthn verification is performed in-house, with no third-party passkey service.
• → An anonymised internal ID is generated at account activation and used in processing logs, decoupling audit records from your direct identifiers.

Your agent: standard OAuth, scoped, instantly revocable

• → Authorization Code + PKCE for standard MCP clients (e.g. Claude, Open WebUI). The client discovers Methos via .well-known metadata and registers itself dynamically — which grants nothing on its own. Access is bound on a Methos consent screen where you pick exactly one profile and the data-category scopes to grant (nothing is preselected; an empty grant is refused). Only PKCE S256 is accepted; your browser session is never shared with the agent.
• → Client credentials for server-to-server use: you create a profile-scoped API key with a name, allowed scopes, and expiry. The secret is shown exactly once and stored only as a Vault Transit HMAC — never in cleartext.
• → Tokens carry no authority. Access tokens (1 h) contain no profile or scope claims. On every MCP call, the stored key or client is looked up server-side — so revoking a key, editing its scopes, or its expiry takes effect immediately, regardless of any token's remaining lifetime. A token can never grant more than the scopes you configured.
• → You manage API keys and authorised clients (list, edit scopes, revoke) from the account portal.

Human-in-the-loop at ingestion

1. 1.You submit data (file upload or manual text entry). The content is transmitted to the backend over TLS-secured gRPC.
2. 2.An AI model reads the content and determines a data category. Content classified as suspicious is quarantined and processed no further.
3. 3.For a category that is normalised, the original content is encrypted and persisted first. An AI model then produces the normalised, anonymised form (PII stripped).
4. 4.You are shown the normalised content and must explicitly confirm it, correct it, or cancel. Nothing is chunked or embedded before this confirmation.
5. 5.Only after you confirm is the normalised content encrypted, split into chunks, and stored; each chunk is then vectorised and the entry is marked searchable.

The AI output at steps 2–3 is a categorisation and normalisation proposal only. It carries no health interpretation and has no effect on the retrievable representation until you review and approve it at step 4.

Models used

Model versions are pinned at deployment and reviewed periodically. No model receives personal data beyond the specific content required for the operation in progress.