Subprocessor Register

KAPUA Labs LLC, doing business as Fronset — Fronset inference and evaluation API

Version 2026-11-05 · Last updated 5 November 2026

This page is the current Subprocessor register referred to in our Privacy Policy (§7.3) and in our Data Processing Agreement (§7.4 and Annex B). It is the authoritative statement of the current Subprocessor set; where an executed DPA is in place and its Section 7.1 table differs from this page, this page governs.

1. How changes to this register work

We give at least thirty days’ notice before a new subprocessor begins processing customer data, or before an existing one is replaced. Notice is given two ways at once: by email to each customer’s registered account address, and by updating this page and its change log in §4.

A customer may object on reasonable data protection grounds within that period. We will discuss any objection in good faith; if it cannot be resolved, the customer may terminate the affected service without penalty.

2. Infrastructure and business subprocessors

These parties process customer data on our behalf, under written agreements imposing data protection obligations sufficient to meet our own.

Not separate subprocessors. The primary datastore and the task broker are self-hosted by us on the Azure compute listed above, in Azure Central US.

3.1A Operator-supplied serving — model providers ARE subprocessors

Where a task model is served in the operator-supplied access mode, we call the provider on our own account and bill you for the usage. On that path the model providers are our subprocessors, because your content reaches them under our account and on our instructions. This is DPA §7.2A, and it is the ordinary case: it is the mode every task model in this service uses unless you have vaulted your own provider key and the task model is configured to use it.

Where your credentials serve the call (§3.1), the provider is not our subprocessor — your agreement with that provider governs, and it bills you directly.

Payment processing. Billing contact and payment data are collected by Stripe, LLC — card data through a Stripe-hosted checkout, and bank transfers into an account Stripe holds for the customer — and cardholder data does not reach our systems. For that data Stripe acts as an independent controller determining its own purposes and means, not as our subprocessor, and its own terms govern that processing.

3. Model providers

Model providers are treated differently depending on whose credentials the call runs on. The distinction is structural, not customary: credential resolution for a customer account reads only that account’s own stored credentials and never falls back to ours. A missing or revoked credential causes the call to fail rather than run on our account.

3.1 Calls on the customer’s own credentials — not our subprocessors

This path covers both ordinary serving traffic and benchmark execution on uploaded evaluation inputs. Each call is made using the customer’s own provider credentials, under the customer’s own agreement with that provider, and benchmark calls are billed to the customer as inference usage. The provider acts as the customer’s processor and we act as a conduit, so on this path the model providers are not our subprocessors and the provider’s own terms govern what it may do with the content.

Because credential resolution never falls back to our credentials, a customer determines which providers can receive its data on this path by choosing which credentials to supply. This is enforced by the service. You control which models, and therefore which providers and serving regions, receive your content by the model group of a task of your own; the serving region of each model is shown in the table above and where you select models and model groups. A shared task runs only on models in the model group we set for it, and a call cannot change that group. The models that evaluate and judge your content, and that adapt the task’s prompt template (which you can switch off for a task of your own), are selected by us as part of our own workloads.

The providers available in bring-your-own-key mode are those in the table in §3.1A, plus Groq, Perplexity, Meta and MiniMax direct. Their establishment is stated per row; several contract through Singapore companies whose groups are in the People’s Republic of China.

One provider’s terms differ materially by billing status. Google’s Gemini API applies different data-use terms to unpaid projects, under which it uses submitted content and generated responses to improve its products, and human reviewers may read and annotate API input and output. The service does not detect the billing status of a supplied credential. Choosing a paid provider project is the customer’s responsibility.

3.2 Calls on our credentials — our subprocessors

One operation runs on our own provider credentials, pinned explicitly rather than inherited from the calling account: model-introduction replay, in which we re-execute retained free-tier prompt content against newly introduced models. On this path the model providers listed in §3.1 are our subprocessors, because customer content is transmitted under our own account.

This operation is performed for our own purposes, returns the customer no result, and is not billed. It applies only to the free tier — no content on the shared_anon or private tiers travels this path. A customer’s choice of credentials does not constrain the providers reached, because the roster is ours. A customer that does not want its content on this path should not use the free tier.

Benchmark execution is not on this path. Uploaded evaluation inputs are nonetheless exempt from tier retention limits — a set is retained on every tier, including private, so it can be re-executed for a further benchmark. That retention is acknowledged at upload, and a run whose set carries no acknowledgement is refused.

4. Change log

5. Objections and contact

Send objections and questions to privacy@fronset.ai, quoting the register version above.