Sub-processors
This page is the customer-facing list of sub-processors engaged for the lynox Managed Hosting service. The contractually binding list lives in the Data Processing Agreement — if any version diverges, the DPA prevails. The same list is also mirrored as a public reference at SUBPROCESSORS.md in the source repo.
This list applies only to lynox AI's managed offering. The self-hosted lynox software (@lynox-ai/core) is a different case: what it connects to is not limited to the LLM provider whose API key you configure. It follows from how you configure the deployment and what you ask the agent to do — a default install reaches a web-search backend, and connected accounts, third-party APIs and addresses the agent is asked to fetch are contacted by your deployment directly.
Whether any of those third parties is a sub-processor, a recipient, or neither depends on your deployment and your own role as controller. This page does not answer that question, and does not need to: it lists the sub-processors lynox AI engages for the managed service. For processing lynox AI carries out for you, the binding text is the Data Processing Agreement.
Current sub-processors
| Sub-processor | Purpose | Location | Transfer mechanism |
|---|---|---|---|
| Anthropic, PBC | Primary LLM inference (Claude family, direct API) | United States | SCCs (2021/914, Modules 2/3) + Swiss and UK addenda (per Anthropic's Data Processing Addendum) |
| Mistral AI SAS | Inference and voice in the default managed setup: the background worker profile (ministral-14b-2512), the fallback profile for named sub-agent spawns (mistral-medium-2604), speech-to-text (voxtral-mini-2602) and text-to-speech (Voxtral). Text-to-speech has no alternative implementation — spoken output always goes to Mistral; on a managed instance neither can be switched away — transcription_provider is not tenant-writable and LYNOX_TRANSCRIBE_PROVIDER is self-host-only, so the local whisper.cpp fallback in the image is unreachable there. Mail-triage classification does not run here by default — it follows the instance's main provider, which is Anthropic unless the customer changes it. Any customer may select Mistral as their main inference provider to keep primary inference within the EU. | France (EU) | EU — processed in France, no third-country transfer. Retention is not zero by default: Mistral keeps API inputs and outputs "for the period necessary to generate the Output and then for thirty (30) rolling days to monitor abuse" (Mistral Privacy Policy, section 5). Mistral's Zero Data Retention is an opt-in option — Scale plan only, stateless endpoints only, granted on request at Mistral's discretion — and its Data Processing Addendum contains no zero-retention commitment. lynox does not hold Zero Data Retention (its Mistral account is on Pay-as-you-go, verified 2026-08-11). Separately, lynox has not enabled training in its Mistral organisation settings and has Labs/Preview off — account configuration rather than contractual terms, checked 2026-08-11. No training on API inputs or outputs — contractual, under Mistral's Commercial Terms of Service §4.2. |
| Fireworks AI, Inc. | LLM inference for the opt-in "Efficient" and "Balanced" model strategies — engaged for a managed instance by one of two routes: the instance selects one of those presets (or a Fireworks model) in its own model settings, or we pin a preset for that instance from the control plane. A pin takes effect only where the instance has not chosen a strategy itself — an instance that has chosen one keeps its choice. We enable the option platform-wide, but neither route is the default: an instance with no selection and no pin routes to Anthropic and Mistral only, and nothing reaches Fireworks until one of the two routes applies. Where a preset is selected, all three model tiers (fast / balanced / deep) run on Fireworks' serverless inference on open-weight models of Chinese origin — DeepSeek v4 Flash, MiniMax M3, GLM 5.2 and Kimi K3. The weights are open; the inference runs on Fireworks' own infrastructure. None of the sub-processors listed in Schedule 4 of its DPA is a Chinese entity. The processing locations named there include the United States, Germany, the United Kingdom, Japan and Iceland; one row, a content-delivery provider, is listed with no fixed country at all. Schedule 4 is Fireworks' list and can change — it is the list as we read it on 2026-08-11, and Fireworks owes 30 days' notice of changes to it (Fireworks DPA, Schedule 4). Fireworks does not retain prompt inputs or model outputs beyond the lifecycle of a request (Zero Data Retention — Fireworks' default for open models, which we have not opted out of by enabling prompt logging, and a contractual obligation under §4.5 of its DPA), and is contractually prohibited from using the data to train, fine-tune or otherwise improve any shared or foundational model (§4.3(f)). | United States | SCCs (2021/914, Module 2; Irish law, Irish DPC); Zero Data Retention and the no-training commitment as additional safeguards; SOC 2 Type II, ISO 27001 / 27701 / 42001 |
| Stripe, LLC (US) / Stripe Payments Europe, Limited (Ireland) | Payment processing and subscription billing | Ireland (EU) — as a customer outside North and South America, our contracting entity is Stripe Payments Europe, Limited. The onward transfer to Stripe, LLC in the United States happens inside the Stripe group. | For lynox's own leg: EU — no third-country transfer, our counterparty being Stripe Payments Europe, Limited (Ireland). For Stripe's onward transfer to Stripe, LLC (US): EU-US and Swiss-US Data Privacy Framework. Stripe's Data Transfers Addendum §2 makes the mechanisms mutually exclusive and gives the Data Privacy Framework precedence, so the SCCs (2021/914) are a fallback that activates only if the DPF ceases to apply — not a second mechanism running alongside it. |
| Hetzner Online GmbH | Server infrastructure — shared tenant hosts (isolated container per customer); dedicated VPS as Enterprise upgrade | Germany (EU) | EU |
| Brevo (Sendinblue SAS) | Transactional email delivery (SMTP relay) and contact list management | EU (France/Germany) | EU |
| Cloudflare, Inc. | DNS, CDN, DDoS protection, tunnel relay. TLS terminates at the Cloudflare edge, so Cloudflare has plaintext visibility on incoming HTTPS traffic before it is re-encrypted to our origin. | United States / EU (edge network) | EU-US and Swiss-US Data Privacy Framework. Cloudflare's Data Processing Addendum sequences the mechanisms rather than stacking them: a transfer made under the Data Privacy Framework is defined as not a Restricted Transfer (cl. 6.4), so the standard contractual clauses in cl. 6.2 do not engage. Should Cloudflare's Data Privacy Framework certification lapse or be invalidated, the same clause deems the transfer Restricted immediately and cl. 6.2 applies, with Cloudflare undertaking to notify us. The SCCs are therefore the contractual fallback, not a second mechanism running alongside. |
| Plausible Insights OÜ | Anonymous website analytics (no personal data) | EU (Estonia) | EU |
| Google (entity per the account's Analytics terms — see mechanism) | Marketing measurement on lynox.ai only — Google Analytics 4 + Google Tag Manager (Consent Mode v2; fires only with marketing consent via Klaro). A Managed Hosting instance also runs its own search service, which queries public search engines on the customer's behalf. Where Google is among them, what reaches Google is the search text together with ordinary HTTP request headers; no account, tenant or user identifier is sent, and the request carries no identifier of the instance beyond its network address. Instances created under the current provisioning configuration do not query Google; instances created earlier do, until their search configuration is regenerated. Beyond that, tenant data reaches Google only where the customer separately enables a Google integration. | United States, or the EEA where the account contracts with a Google entity there | Google's terms name the contracting entity as "Google LLC, Google Ireland Limited or any other Affiliate of Google LLC", and which one applies follows the Analytics terms accepted for the account. lynox's account is Swiss-domiciled and no Swiss variant of those terms is published, so we do not assert which entity it is. Where it is Google LLC (US), Google's EU-US and Swiss-US DPF certification applies (US Department of Commerce register, retrieved 2026-08-23: Google LLC is listed with the EU-U.S. framework, the UK Extension and the Swiss-U.S. framework each Active, and a next certification due date of 2026-09-13 for each — a re-certification deadline rather than an expiry date; the listing remains Active unless a renewal is missed. For lynox's own Swiss-domiciled leg the operative framework is the Swiss-U.S. one. The listing covers Google LLC and its wholly-owned US subsidiaries only to the extent such a subsidiary maintains its own current self-certification) with SCCs (2021/914, Module 2) as Google's stated fallback; where it is a Google entity in the EEA, no third-country transfer arises on this leg. Module 3 is not ours — it governs Google's own onward transfers. |
| Self-hosted (Bugsink) | Error reporting (always active for managed instances) | EU (self-hosted on lynox infrastructure) | No third-party transfer |
Prompt caching. Prompt prefixes are cached to cut latency and cost: on Anthropic we set explicit cache breakpoints, while Mistral and Fireworks apply their own automatic prefix caching. Cached data is short-lived and expires on its own: our Anthropic cache breakpoints carry a one-hour time-to-live, and for Fireworks its documentation states the data stays in volatile memory and is never written to persistent storage. Caching is the one carve-out from the Fireworks zero-retention commitment cited in the table.
Customer-configured endpoints (BYOK). If you connect your own LLM provider via Settings → LLM — for example OpenAI, an OpenAI-compatible endpoint, Google Vertex AI, or a self-hosted model — that provider is engaged by you under your own agreement with it. It is not a lynox sub-processor and is not listed above; you act as controller for that transfer. See "Customer-configured endpoints" in the DPA.
Change notification
We notify Managed Hosting customers at least 30 days in advance of any addition or replacement of sub-processors, per section 8.4 of the DPA. To subscribe to sub-processor change notifications or object to a change, contact privacy@lynox.ai.
Contact
For questions about sub-processors:
privacy@lynox.ai · EU representative: Prighter portal