Subprocessor Register

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

Version 2026-09-15 · Last updated 15 September 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.

All of our infrastructure and all of the subprocessors above are located in the United States.

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 through a Stripe-hosted checkout, 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 — and, where a provider operates region-scoped endpoints, the same choice determines the region the call is served from. This is enforced by the service.

The currently registered provider set is: Anthropic, OpenAI, Google (Gemini), Groq, Meta, xAI, Perplexity, OpenRouter, DeepSeek, Moonshot AI, Z.AI, MiniMax, and Alibaba Cloud (DashScope). Several are established outside the United States, the EU and the UK, including in the People’s Republic of China — specifically DeepSeek, Moonshot AI, Z.AI, MiniMax and Alibaba Cloud.

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 llmbench@kapualabs.com , quoting the register version above.