DATA PROCESSING AGREEMENT

KAPUA Labs LLC, doing business as Fronset — Fronset Inference and Evaluation API

Version 2026-09-15 (date-based versioning) · Effective as of the date of Customer’s acceptance

Version 2026-09-15 supersedes 2026-09-14: the Service is renamed Fronset and the trading name is added to the Processor’s entity line; the register and version-history addresses in Sections 7.4 and 15.4 and Annex B move to fronset.ai/legal/. No term changed.

Version 2026-09-14 supersedes 2026-09-08: Section 6 now states that Model Output on the shared_anon and private Service Tiers is retained only until delivery and evaluation (the fixed expiry Section 6.2 previously said would be notified — this version is that notice), that a Registered Template’s taxonomy evaluation is one-time and bounded and that Customer may then delete the Template text, and that evaluation evidence is retained for Customer’s review only on Customer’s own criteria and for a window Customer controls; Section 8.1’s retrieval and export rights are narrowed to match; the Section 8.3(a) exclusion of Registered Template content from erasure is withdrawn — Template text is now erased; and Section 9.4 describes the continuous retention sweep.

Version 2026-09-08 superseded 2026-08-21: Section 7.1’s Model Providers row and Annex B’s enumeration are brought into line with Section 7.2A (operator-supplied serving), which they contradicted; Metronome, Cloudflare and tawk.to are added to the register; and Section 9.5’s error-monitoring description is corrected to state what the configuration does. This DPA was previously versioned 1.0 and 1.1. From version 2026-08-21 it shares the date-based version namespace used by the Terms of Service and the Privacy Policy, so that one version string identifies one text across all three documents and across the consent record. Version 2026-08-21 carries the same terms as 1.1.

This Data Processing Agreement (this “DPA”) forms part of and is incorporated into the Terms of Service between KAPUA Labs LLC, doing business as Fronset, and Customer (the “Agreement”) governing Customer’s use of the Fronset inference and evaluation API (the “Service”). In the event of a conflict between this DPA and the Agreement with respect to the processing of Customer Content, this DPA controls.

1. Definitions

“Customer” means the entity identified in the Order Form or account record that accepts the Agreement.

“Customer Content” means Prompt Content, Model Output, Batch Input Files, Evaluation Inputs, Registered Templates, Provider Credentials and Webhook Destinations, as each is described in Section 3.1.

“Personal Data” means any information relating to an identified or identifiable natural person, and includes “personal information” and “personal data” as defined under Applicable Privacy Law, to the extent contained within Customer Content.

“Applicable Privacy Law” means all privacy, data protection and data security laws applicable to a party in its role under this DPA, including the California Consumer Privacy Act as amended by the California Privacy Rights Act and its implementing regulations (together, the “CCPA”), the comprehensive consumer privacy statutes of other U.S. states, and, to the extent Processor makes them applicable by written addendum under Section 12, the EU General Data Protection Regulation and the UK GDPR.

“Controller” means Customer. “Processor” means KAPUA Labs LLC. Where the CCPA applies, Customer is the “business” and KAPUA Labs LLC is the “service provider.”

“Model Provider” means a third-party provider of large language model inference accessible through the Service.

“Subprocessor” means a third party engaged by Processor that processes Customer Content on Processor’s behalf.

“Service Tier” means the retention and use tier (free, shared_anon, or private) selected by Customer and recorded in Processor’s append-only consent record.

“Operator-supplied access mode” means the mode in which Processor supplies the model access on its own Provider Credentials and bills Customer for the usage (Section 7.2A), as opposed to the bring-your-own-key access mode, in which Customer supplies the Provider Credential and contracts with the Model Provider directly (Section 7.2). It is the mode the Service, its portal and its documentation call managed: the two names describe one arrangement and nothing else, and this DPA uses “operator-supplied” throughout.

2. Parties, Subject Matter and Duration

3. Categories of Data

3.1 Customer Content

3.2 Data Subjects and Categories of Personal Data

The Service imposes no schema on Prompt Content and Processor has no technical means of detecting whether Personal Data is present within it. Customer is solely responsible for determining what Personal Data, if any, it submits and to which data subjects that data relates.

3.3 Data Processed by KAPUA Labs as Controller

Account, authentication, consent, billing and support data are processed by KAPUA Labs LLC as a controller in its own right. That processing is governed by the KAPUA Labs Privacy Policy and is otherwise outside the scope of this DPA, except that Section 8.2(g) applies to its erasure and Section 10 applies to a security incident affecting it.

3.4 Prohibited Content

Customer shall not submit to the Service:

(a) on the free Service Tier, any Personal Data (see Section 6.4), and on any Service Tier, any Personal Data within a Registered Template or a registered output schema (see Section 6.4; Template content on free and shared_anon is evaluated for and may be adopted into the canonical library under Section 6.1, and a registered schema is an erasure exclusion under Section 8.3(a) on every tier including private);

(b) on any Service Tier, protected health information subject to the Health Insurance Portability and Accountability Act, cardholder data subject to the Payment Card Industry Data Security Standard, information subject to the Gramm-Leach-Bliley Act, government-issued identification numbers, biometric identifiers, or the personal data of children under the age of thirteen, unless the parties have executed a written amendment expressly permitting it. That amendment is available only where this DPA is executed under Section 15.2.

Processor has no technical means of detecting a breach of this Section and relies on Customer’s compliance.

4. Processor Obligations

4.1 Processing on Documented Instructions

Processor shall process Customer Content only on Customer’s documented instructions. Customer’s API calls, together with the Service Tier selection and the configuration Customer maintains on the management plane, constitute those instructions. The processing Processor performs consists of executing those calls and, in addition:

(a) the model-judging and evaluation operations that Customer instructs by requesting an evaluation or benchmark, which take Prompt Content and Model Output as inputs and produce content-free verdicts and cost and latency statistics;

(b) Service Tier-dependent retention and use as set out in Section 6;

(c) retention of Evaluation Inputs beyond Service Tier limits, so that an uploaded evaluation set can be re-executed on Customer’s request (Section 7.3); and

(d) on the free Service Tier only, model-introduction replay under Sections 6.3 and 7.3, which Processor performs for its own purposes as the consideration for that tier.

Retention is enforced at a single write chokepoint in the Service, which fails closed: an unknown, missing or unreadable Service Tier is treated as the most restrictive tier.

Processor shall notify Customer if, in Processor’s reasonable opinion, an instruction infringes Applicable Privacy Law.

4.2 No Cross-Customer Processing

Processor warrants that:

(a) where an evaluation or benchmark draws on historical calls, it draws only on Customer’s own call history, enforced by tenant-scoped data access at the persistence layer;

(b) evaluation reference examples are scoped to the evaluating tenant; and

(c) Customer Content is never submitted within another customer’s evaluation prompt or judge prompt, except as permitted by the shared-judging exception below.

Every deliberate cross-tenant read path in the Service is enumerated in a controlled allowlist enforced by an automated test in Processor’s build pipeline, which fails on both unregistered new reads and stale entries.

Shared-judging exception (free and shared_anon Service Tiers only). On the free and shared_anon Service Tiers, Processor may include Customer’s Model Output — and no other Customer Content — in the same judge prompt as another customer’s Model Output for the same capability, so that both are scored on one consistent scale. Where Processor does so: the judge model receives Model Output only, without Customer’s identity or any other Customer Content; Processor does not disclose Customer’s Model Output to the other customer, or that other customer’s Model Output to Customer; and the resulting verdict is retained and used as otherwise provided in this DPA. This exception does not apply, and Processor makes no such disclosure, on the private Service Tier.

4.3 Confidentiality of Personnel

Processor shall ensure that each person authorised to process Customer Content is bound by a written obligation of confidentiality that survives the termination of their engagement, and shall limit access to Customer Content to those personnel who require it to perform Processor’s obligations under the Agreement.

4.4 Assistance to Customer

Taking into account the nature of the processing and the information available to it, Processor shall provide reasonable assistance to Customer in:

(a) responding to verified requests from data subjects or consumers, to the extent and by the means described below;

(b) conducting data protection impact assessments and consulting with regulators or supervisory authorities where required; and

(c) meeting Customer’s own security, breach-notification and record-keeping obligations.

Limits Customer must account for in its own compliance programme. Processor cannot identify which stored records relate to a given individual, because Prompt Content is unstructured and Processor applies no schema to it. Processor’s assistance with individual requests is therefore limited to: tenant-wide erasure under Section 8; erasure or amendment of a specific record that Customer identifies to Processor by record identifier; and the provision of the information described in Section 13. Processor cannot perform a content search for an individual across Customer’s tenant, and cannot action an access, correction, or restriction request at the level of an individual data subject. Customer is responsible for maintaining whatever record-level mapping its own obligations require.

4.5 Notice of Inability to Comply

Processor shall notify Customer promptly, and in any event within five business days, if Processor determines that it can no longer meet its obligations under this DPA or under Applicable Privacy Law.

5. Controller Obligations and Warranties

Customer warrants and undertakes that:

(a) it has a lawful basis for, and has provided all notices and obtained all consents required for, the Customer Content it submits and the processing instructed under this DPA;

(b) it will not submit Customer Content outside the scope agreed in Section 3, including the prohibitions in Section 3.4;

(c) it maintains its own agreements with each Model Provider whose Provider Credentials it stores with the Service, and its use of those credentials through the Service complies with those agreements;

(d) its processing instructions comply with Applicable Privacy Law; and

(e) it will select the Service Tier appropriate to the sensitivity of the Customer Content it submits, having read Section 6.

6. Retention and Service Tiers

6.1 The Retention Matrix

Customer selects a Service Tier at signup, which is version-stamped in an append-only consent record. The Service Tier determines retention and use as follows.

6.2 Model Output

Model Output is retained on every Service Tier. Retention is necessary because three delivery paths reconstruct Customer’s own deliverable from the stored response after a call finalizes: webhook payloads are rebuilt at send time, Batch API output files are rendered at finalization, and Customer’s own retrieval endpoint serves the response back, which is also the recovery path for an undelivered webhook.

Processor retains Model Output for the period necessary to deliver the result to Customer, to serve Customer’s own retrieval requests, to perform the evaluation and judging operations Customer has instructed under Section 4.1(a), and, on the free Service Tier only, as a comparison baseline in model-introduction replay under Section 4.1(d). Processor does not use Model Output for any other purpose.

On the shared_anon and private Service Tiers, that period is bound to delivery. Processor deletes the Model Output of a call promptly — ordinarily within minutes — once it has been delivered to Customer and any evaluation of it has completed. Model Output that could not be delivered is retained for Customer’s retrieval for no more than seventy-two hours and then deleted. No retrieval or export of Model Output is available on these tiers beyond that, and Customer is responsible for retaining what it fetches. The single exception is the evaluation evidence Customer elects to retain under Section 6.7. Batch input files on these tiers are deleted once every line of the batch has reached a terminal state, and in any case within the same seventy-two hours.

On the free Service Tier, Model Output is retained until erased on Customer’s request or on termination in accordance with Section 8; once delivery is complete Processor may also delete it at its own discretion to manage storage.

This Section is the notice of a fixed expiry period that the prior version of this DPA undertook to give. A later lengthening of the retention of Model Output on shared_anon or private is an amendment to this DPA under Section 14; a shortening is not.

6.3 Prompt Content on the free Tier

On the free Service Tier, and only on that tier, the request body of Prompt Content is retained and used by Processor for its own purposes, namely re-execution against newly introduced models and taxonomy development. This use is the consideration for the free tier.

On the shared_anon and private tiers, the request body is not written to persistent storage. Customer should note that this guarantee attaches to the request body and not to every artifact in which request content could appear. Specifically:

• on the shared_anon tier the Service retains a derived routing embedding of the request, which Processor treats as content because it is partially invertible (see Section 8.2(d)). Embeddings are not retained on the private tier;
• Registered Template content, including verbatim system-prompt text, is retained on every tier under Section 6.1; and
• Section 8.3 identifies further stores that may contain fragments of request content on any tier.

6.4 Where Processor Does Not Act as a Service Provider

Processor uses two categories of Customer Content for its own purposes rather than solely to perform the Service:

(a) free-tier Prompt Content, as described in Section 6.3; and

(b) Registered Template content on the free and shared_anon tiers, which Processor uses for taxonomy and canonical mapping as shown in Section 6.1.

With respect to those two categories, Processor does not act as a “service provider” under the CCPA, and Section 11 does not apply to them. Customer shall not submit Personal Data within either category, as required by Section 3.4(a).

Notwithstanding that Section 11 does not apply to those two categories, Processor shall not sell or share them, as “sell” and “share” are defined under the CCPA, and shall use them only for performing the Service and for the additional purposes stated in Section 6.3 and Section 6.1 respectively.

Customer requiring service-provider treatment under Section 11 for all Customer Content should select the private Service Tier, on which the request body is not retained and Registered Template content is used only within Customer’s tenant. The private tier additionally retains no derived routing embedding; on the free and shared_anon tiers an embedding is retained and used to perform the Service, and Processor treats it as content because it is partially invertible.

Customer should note that Section 3.4(a) prohibits Personal Data in Registered Templates on all tiers: on free and shared_anon Template content is evaluated for, and may be adopted into, the canonical library under Section 6.6, and on every tier the content-free record of which Template version ran a call survives erasure (Section 8.2(a)).

6.5 Tier Changes Are Forward-Only

A change of Service Tier applies to Customer Content processed after the change takes effect. Content-free verdicts already pooled across customers will not be withdrawn from that pool on a tier change, save that Processor reserves the right to re-classify pooled verdicts to correct an error.

6.6 Registered Templates — One-Time Evaluation and Customer Deletion

On the free and shared_anon Service Tiers, Processor compares each Registered Template with its canonical library once, within a bounded period of the capability’s creation, to map it and to decide whether to adopt it (Agreement §9). When that evaluation is complete Processor deletes the material it retained for the purpose, including any derived routing embedding, and Customer may thereafter delete the Template text through the Service. On the private Service Tier no such evaluation takes place and Customer may delete the Template text at any time. Deletion removes the text of every stored version; the content-free record of which version ran a given call is retained. Deletion does not withdraw a licence already exercised under Agreement §9.

6.7 Evaluation Evidence Retained for Customer’s Review

Where Customer sets its own evaluation criteria for a capability, Processor retains, for that capability only, a copy of each evaluated exchange — the material shown to the judge, the candidate Model Outputs and the resulting verdicts — for a review window that Customer controls through the Service, not exceeding the maximum Processor publishes there, and deletes it when the window closes. Customer may shorten the window at any time, including to nil. The retention is for Customer’s own review and is processed on Customer’s instruction under Section 4.1(a); it does not extend the retention of any other Customer Content and is erased under Section 8.2.

7. Subprocessors

7.1 Authorised Subprocessors

Customer grants Processor general written authorisation to engage the Subprocessors listed below.

The primary datastore and the task broker are self-hosted by Processor on the Azure compute above and are not separate Subprocessors. They are located in Azure Central US.

Payment processing. Customer’s billing contact and payment data are collected by Stripe, LLC through a Stripe-hosted checkout. Cardholder data does not reach Processor’s systems. For that data Stripe acts as an independent controller determining its own purposes and means, not as Processor’s Subprocessor, and its processing is governed by Stripe’s own terms with Customer and with Processor rather than by this DPA.

7.2 Model Providers Accessed with Customer Credentials

This Section describes the bring-your-own-key access mode. Where a capability is served in the operator-supplied access mode, Section 7.2A applies instead. The access mode is declared on each capability and is visible to Customer.

In bring-your-own-key mode, each call is made using Customer’s own Provider Credentials, under Customer’s own agreement with that Model Provider. This is structural rather than customary: in this mode credential resolution for a customer tenant reads only that tenant’s stored credentials and does not fall back to Processor’s own credentials. A missing or revoked credential causes the call to fail rather than to be executed on Processor’s account. The Service additionally supports a zero-custody mode in which a Provider Credential is supplied on a per-request header and is never persisted.

For this path, the Model Provider acts as Customer’s own processor under Customer’s agreement with that Model Provider, and Processor acts as a conduit. The Model Providers are not Processor’s Subprocessors on this path.

Customer control over the provider set and the serving region. Because credential resolution does not fall back to Processor’s credentials, Customer determines which Model Providers can receive its Customer Content on this path by choosing which Provider Credentials to supply. The eligible model pool for any capability is the intersection of that capability’s models with the providers for which Customer has supplied a credential, whether stored in the vault or presented on a per-request header, and this constraint is enforced by the Service. Where a Model Provider operates region-scoped endpoints, the credential Customer supplies is bound to one of them, so the same choice also determines the region the call is served from — see Section 12.3. This path covers both ordinary serving traffic and benchmark execution on Evaluation Inputs. The control does not constrain the free-tier replay described in Section 7.3, which executes on Processor’s own credentials.

The Model Providers available through the Service are: Anthropic, OpenAI, Google (Gemini), Groq, Meta, xAI, Perplexity, OpenRouter, DeepSeek, Moonshot AI, Z.AI, MiniMax, and Alibaba Cloud (DashScope).

7.2A Model Providers Accessed with Processor Credentials — Operator-Supplied Serving

The operator-supplied access mode is the mode the Service, its portal and its documentation call managed (Section 1). The two names describe one arrangement, and nothing else answers to either.

Where a capability is served in the operator-supplied access mode, Processor supplies the model access on its own Provider Credentials and bills Customer for the usage. On this path the Model Providers are Processor’s Subprocessors, because Customer Content is transmitted to them under Processor’s own account and on Processor’s instructions.

Three consequences follow:

(a) The notice and objection rights in Section 7.4 apply to this path in full. The Model Providers reached in this mode are listed in the Subprocessor register, and Processor gives the thirty days’ notice required by Section 7.4 before adding or replacing one.

(b) Customer cannot constrain the provider set by its choice of Provider Credentials, because the roster is Processor’s. Where a Model Provider operates region-scoped endpoints, the serving region is Processor’s choice and is surfaced with the model under Section 12.3.

(c) The Service Tier retention terms in Section 6 apply unchanged. The access mode determines who contracts with the Model Provider; it does not alter what Processor retains, what it may reuse, or Customer’s rights under Sections 8 and 11.

Unlike the free-tier replay in Section 7.3, this path serves Customer’s own requests, returns Customer the result, and is billed to Customer. It is available on every Service Tier.

7.3 Model Providers Accessed with Processor Credentials

One further operation executes on Processor’s own Provider Credentials, pinned explicitly rather than inherited from the calling tenant, and is distinct from the operator-supplied serving described in Section 7.2A: model-introduction replay, in which Processor re-executes free-tier Prompt Content against newly introduced models as described in Section 6.3. On this path the Model Providers are Processor’s Subprocessors, because Customer Content is transmitted under Processor’s own account.

This operation is performed for Processor’s own purposes, returns Customer no result, and is not billed to Customer. It applies only to the free Service Tier. No Customer Content on the shared_anon or private tiers travels this path.

Customer cannot constrain the Model Providers reached on this path by its choice of Provider Credentials, because the roster is Processor’s. A Customer that does not wish its content to travel this path should not use the free Service Tier.

Evaluation Inputs and benchmark execution are not on this path. Where Customer uploads Evaluation Inputs and requests a benchmark, execution uses Customer’s own Provider Credentials under Section 7.2, and the resulting calls are billed to Customer as inference usage. The Model Providers are therefore not Processor’s Subprocessors for benchmark execution on any Service Tier.

Customer should note that Evaluation Inputs are nonetheless exempt from Service Tier retention limits: an uploaded evaluation set is retained on every tier, including private, so that the set can be re-executed when Customer requests a further benchmark. The Service records Customer’s acknowledgement of that retention at the time Evaluation Inputs are uploaded, capturing the identity of the uploading user and the time of upload, and refuses to execute an evaluation set for which no acknowledgement is recorded. Evaluation Inputs are erased under Section 8.2.

7.4 Subprocessor Obligations and Changes

Processor shall enter into a written agreement with each Subprocessor that imposes data protection obligations sufficient to enable Processor to meet its own obligations under this DPA. Where a Subprocessor offers only standard, non-negotiable terms, Processor shall procure that Subprocessor’s standard data protection terms and shall not engage a Subprocessor whose standard terms are insufficient for that purpose. Processor remains responsible to Customer for a Subprocessor’s processing of Customer Content to the same extent as for its own, subject to the limitations of liability in Section 14.2.

The Model Providers identified in Section 7.2 are not Subprocessors on that path and this Section does not apply to them in that capacity.

Processor maintains the current Subprocessor register at https://fronset.ai/legal/subprocessors/ . Processor shall give Customer at least thirty days’ notice before adding or replacing a Subprocessor, by email to Customer’s registered account address and by updating the register. Customer may object on reasonable data protection grounds within that period, in which case the parties shall discuss in good faith; if the objection cannot be resolved, Customer may terminate the affected Service without penalty.

8. Deletion and Return

8.1 Return of Customer Content

During the term, and following termination until erasure commences under Section 8.2, Customer may retrieve through the Service’s retrieval endpoints whatever Model Output and Batch API output files Processor still retains under Section 6.2 — on the free Service Tier, all of it; on the shared_anon and private Service Tiers, only an undelivered result within the seventy-two hours Section 6.2 allows, since delivered Model Output is deleted. Processor shall give Customer at least seven days’ written notice before commencing erasure following termination, so that Customer may exercise its rights under this Section.

On written request made before erasure commences, Processor shall provide Customer, within fourteen days of the request, with a copy of its retained Prompt Content, Model Output, Batch Input Files, Evaluation Inputs, evaluation evidence retained under Section 6.7 and Registered Templates in a structured, machine-readable format — “retained” meaning what Section 6 retains on Customer’s Service Tier at the time of the request; on shared_anon and private, delivered Model Output and Prompt Content are not retained and cannot be exported. Where such a request is outstanding, Processor shall not commence erasure until it has been fulfilled, and the erasure period in Section 8.2 is extended accordingly. This Section does not apply to Provider Credentials or Webhook Destination signing secrets, which Processor does not export.

8.2 Erasure

Processor shall erase Customer Content within thirty days of Customer’s verified written request, or of termination of the Agreement, and shall issue Customer an erasure certificate identifying what was erased and what was retained under Sections 8.3 and 8.4. Customer’s retrieval rights under Section 8.1 end when erasure commences, subject to the notice Processor must give and to any outstanding export request under that Section. The erasure procedure is idempotent, defaults to a dry run, cannot be executed against a Processor-owned tenant, and is followed by a verification query, the report of which is available to Customer under Section 13.

Erasure covers, for Customer’s tenant:

(a) all Prompt Content and content-bearing metadata held on call records, all Model Output, and the text of every Registered Template and every stored version of it (the content-free record of which version ran a call survives);

(b) evaluation dispatch input and output snippets, and the evaluation evidence retained under Section 6.7, which is deleted outright;

(c) judge run candidate and winner payloads across the evaluated model roster;

(d) derived routing embeddings, which are hard-deleted rather than blanked, because an embedding is partially invertible and therefore constitutes content;

(e) Batch API content at rest, comprising every stored file blob — both Customer-uploaded input and service-rendered output and error files — with the corresponding records tombstoned, and every per-line parsed request body blanked; and

(f) Provider Credentials, which are destroyed, and Customer’s service API keys, which are disabled; and

(g) Customer’s account, authentication and support data held by Processor as controller under Section 3.3, other than the records identified in Section 8.4 as surviving.

8.3 Erasure Exclusions

Customer acknowledges that the erasure described in Section 8.2 does not extend to the following, and Processor makes no warranty that Customer Content is absent from them:

(a) Registered output schemas. The structure Customer authored to describe a valid answer is retained; it is configuration rather than content. Customer shall not place Personal Data in a registered schema (Section 3.4(a)). Registered Template content, which this item excluded in prior versions, is now erased under Section 8.2(a).

(b) Provider error messages recorded on call records, which may echo fragments of request content returned by a Model Provider.

(c) Application log files and, where enabled, error-monitoring events. Customer Content is not intentionally written to either, but neither is within the scope of the erasure procedure.

(d) Dormant storage locations — cached idempotency results and unused file-reference columns on call records — which no current Service code path writes to. If Processor brings any such location into active use, Processor shall bring it within the scope of Section 8.2 before doing so.

Processor shall notify Customer if it brings item (a) or (b) within the scope of Section 8.2. Item (a) as it stood in versions before 2026-09-14 — Registered Template content — has been brought within scope; this version is that notice.

8.4 What Survives Erasure

Content-free aggregated verdicts and statistics survive erasure. These carry no prompt or response text; they are scores and counts. On the free and shared_anon Service Tiers, those verdicts have already been incorporated into a cross-customer statistical pool, and an individual customer’s contribution to that pool cannot be identified or reconstructed by a third party from the pooled figures. The erasure certificate reports the number of such records explicitly.

The following also survive erasure: aggregate usage and billing records, retained for the period required by applicable tax and accounting law; and audit-log entries, including the append-only consent record, of which only the request metadata fields are purged.

9. Technical and Organisational Measures

9.1 Tenant Isolation

Customer Content is scoped to Customer’s tenant at the persistence layer by default; access outside that scope requires an explicit, enumerated exception. Every such exception is registered in a controlled allowlist enforced by an automated test that fails the build on both unregistered new cross-tenant reads and stale entries.

9.2 Provider Credentials at Rest

Provider Credentials are protected by envelope encryption. A fresh 256-bit data-encryption key is generated per credential; the secret is encrypted under AES-256-GCM; and the data-encryption key is wrapped by Customer’s own dedicated key-encryption key in Azure Key Vault using RSA-OAEP-256. Ciphertext and the wrapped key are stored in the primary datastore; the key-encryption key never leaves Key Vault. No secret plaintext is stored. Decryption fails closed: a Key Vault outage or a failed unwrap causes the operation to fail rather than to proceed.

Plaintext exists only in worker memory, cached for a configurable period which is 300 seconds by default. That period is also the upper bound on revocation latency in a warm worker. Every materialisation of plaintext writes an append-only audit record capturing purpose, provider and capability, and never key material. Only the final four characters of a credential are retained for display.

9.3 Service API Keys

Service API keys are stored as a SHA-256 digest of the full token, which also serves as the lookup index. The raw token is returned once at issue and is not recoverable. Keys carry a scope, a revocation flag, an optional expiry, and rotation timestamps.

9.4 Retention Enforcement

A single write chokepoint determines retention for every code path, including serving, judging, repair, prompt adaptation and fan-out siblings. It fails closed on an unknown or unreadable Service Tier. Batch working copies of rendered messages are stripped at finalization and again by a daily sweep, which additionally strips records that remain in flight beyond seventy-two hours. The delivery-bound retention of Model Output in Section 6.2 is enforced by a continuous automated sweep keyed on the delivery and evaluation state of each call, with a seventy-two-hour backstop for undelivered results; Processor monitors that the sweep is running and alerts on any call that outlives the schedule.

9.5 Error Monitoring

Error monitoring is enabled only where a reporting endpoint is configured. Where enabled, Processor operates it with default personally-identifiable-information capture disabled and request-body capture disabled — the mechanism by which Prompt Content would ordinarily reach an error event. Local variables are retained in stack traces except for modules that handle credentials or plaintext secrets, whose entire local-variable set is discarded before an event leaves the process. Two composed scrubbing layers then apply: a recursive name-based scrubber extended with the Service’s secret-bearing field names, followed by a pass that redacts dynamic per-request provider-key headers in both HTTP and WSGI forms. Scrubbing fails closed: a scrubbing error causes the carrying fields to be destroyed, and if that fails the event is dropped.

Because local variables and request bodies are excluded, the mechanisms by which Prompt Content would ordinarily be carried into an error-monitoring event do not operate. Processor does not warrant that content can never appear within an exception message string produced by an upstream component, and Section 8.3(c) accordingly places error-monitoring events outside the scope of erasure.

Where error monitoring is enabled, Sentry engages its own subprocessors under its own agreements. Sentry publishes its current subprocessor list at sentry.io/legal/subprocessors.

9.6 Webhooks

Webhook destinations are registered in advance rather than accepted per call. URLs are validated at registration as HTTPS-only and as resolving to a public IP address. The signing secret is generated server-side, displayed once, and stored in the credential vault; the endpoint record holds a reference rather than the value. Delivery records are content-free by design, as the payload is reconstructed at send time, and undeliverable messages are dead-lettered after twenty-four hours.

9.7 Measures Not Currently in Place

Processor does not currently hold SOC 2 Type II or ISO 27001 certification. Processor does not represent that it conducts third-party penetration testing, formal business continuity or disaster recovery testing, or that it maintains documented recovery point or recovery time objectives. Processor has not verified whether database-volume encryption at rest is enabled by its hosting provider, and the measures in Section 9.2 describe the protection of Provider Credentials specifically rather than of the primary datastore as a whole.

Processor shall notify Customer if any of the foregoing changes. Processor’s audit and information obligations are set out in Section 13.

10. Security Incident Notification

Processor shall notify Customer without undue delay, and in any event within seventy-two hours of becoming aware of a breach of security leading to the accidental or unlawful destruction, loss, alteration, or unauthorised disclosure of or access to Customer Content or to the data Processor holds as controller under Section 3.3.

Notification shall be sent to Customer’s registered account email address and shall describe, to the extent known: the nature of the incident and the categories of data affected; the likely consequences; the measures taken or proposed to address it; and a contact point for further information. Processor shall provide further information as it becomes available and shall cooperate reasonably with Customer’s own notification obligations.

Processor maintains an append-only audit record of every materialisation of Provider Credential plaintext (Section 9.2), which supports post-incident review of credential access.

Processor’s detection is alert-driven and is not a continuously monitored security operations function. The seventy-two hour period accordingly runs from Processor’s actual awareness of an incident.

11. CCPA and U.S. State Privacy Law Terms

This Section applies to all Customer Content other than the two categories identified in Section 6.4, which Processor uses for its own purposes and to which this Section does not apply. With respect to the Customer Content within its scope, Processor is a “service provider” or “processor” as those terms are defined under Applicable Privacy Law, and:

11.1 Customer discloses that Customer Content to Processor solely for the limited and specified business purposes described in Section 2 and Section 4.1.

11.2 Processor shall not sell or share that Customer Content, as “sell” and “share” are defined under the CCPA.

11.3 Processor shall not retain, use, or disclose that Customer Content for any purpose other than the business purposes specified in Section 4.1, including for any commercial purpose other than those business purposes, and shall not retain, use, or disclose it outside the direct business relationship between the parties, except as permitted by Applicable Privacy Law.

11.4 Processor shall not combine that Customer Content with personal information it receives from another source or collects from its own interaction with a consumer, except as necessary to perform a business purpose permitted under Applicable Privacy Law. The cross-customer statistical pooling described in Section 6.1 operates only on content-free verdicts and statistics and does not combine Personal Data.

11.5 Processor shall comply with the obligations imposed on service providers and processors under Applicable Privacy Law and shall provide that Customer Content the level of privacy protection required by it, subject to the erasure exclusions Customer has acknowledged in Section 8.3 and to the assistance limits in Section 4.4.

11.6 Customer may take reasonable and appropriate steps to ensure that Processor uses that Customer Content in a manner consistent with Customer’s obligations under Applicable Privacy Law, including through the assessments described in Section 13, which Customer may exercise no more than once in any twelve-month period absent a security incident or a reasonable belief of non-compliance.

11.7 Customer may, on notice, take reasonable and appropriate steps to stop and remediate any unauthorised use of that Customer Content by Processor.

11.8 Processor shall notify Customer in accordance with Section 4.5 if it determines that it can no longer meet its obligations under Applicable Privacy Law.

11.9 Processor shall assist Customer in responding to verified consumer requests as set out in Section 4.4, subject to the limits stated there.

12. International Transfers

12.1 Processor’s own infrastructure

All of Processor’s own infrastructure and all of Processor’s Subprocessors are located in the United States. Compute, the self-hosted primary datastore and task broker, object storage, key management and alerting are in Azure Central US; error monitoring, where enabled, is in the United States region identified in Section 7.1.

12.2 Model Providers — establishment and serving location are different questions

Where a Model Provider is established and where it serves inference from are separate matters, and a Customer’s assessment may turn on either or both.

Establishment is the domicile of the contracting entity. It determines which legal system may compel that entity to disclose data, irrespective of where the data physically sits. The Model Providers established in the People’s Republic of China are DeepSeek, Moonshot AI, Z.AI, MiniMax, and Alibaba Cloud. The remainder are established in the United States or the European Union.

Serving location is where inference is executed and where the Model Provider holds the associated data. It does not follow from establishment. Several Model Providers, including PRC-established ones, operate region-scoped endpoints outside the People’s Republic of China. Alibaba Cloud, for example, serves its models from Singapore, the United States, Germany, Hong Kong and mainland China through separate endpoints with separate credentials, and states that data is held in the region selected.

Customer should note that a provider established in one jurisdiction and serving from another may remain subject to the laws of the jurisdiction in which it is established. Selecting a non-PRC endpoint of a PRC-established provider addresses the location of the data; it does not by itself address the reach of PRC law over the provider.

12.3 How serving location is determined, and what Processor discloses

In the bring-your-own-key access mode, where a Model Provider operates region-scoped endpoints, the serving region follows the endpoint bound to the Provider Credential Customer supplies. Customer therefore selects the serving region by selecting which regional credential to configure — the same mechanism, and the same enforced constraint, by which it selects the provider set under Section 7.2. In the operator-supplied access mode (Section 7.2A) the endpoint is Processor’s choice and is surfaced with the model.

Processor shall surface, in the provider and model information exposed through the Service, the serving region for each Model Provider and model where the Model Provider makes that information determinable, and shall indicate where it does not. Processor takes that information from the Model Provider’s own documentation and endpoint configuration. Processor does not independently verify it, does not warrant its accuracy, and cannot state a serving region for a Model Provider that does not publish one.

12.4 Allocation of responsibility

Where a call is made using Customer’s own Provider Credentials under Section 7.2 — including benchmark execution on Evaluation Inputs on every Service Tier — the transfer is made under Customer’s own agreement with that Model Provider, at an endpoint Customer selected. Customer both controls and is responsible for the transfer assessment.

Where a call is served in the operator-supplied access mode under Section 7.2A, or free-tier Prompt Content is replayed using Processor’s credentials under Section 7.3, Processor is the exporter and selects the endpoint. Customer’s choice of Provider Credentials does not constrain that path. A Customer that does not wish Processor to make that determination on its behalf should not use the free Service Tier.

12.5 European and UK transfers

This DPA does not incorporate the European Commission’s Standard Contractual Clauses or the UK International Data Transfer Addendum, and Processor does not offer the Service for the processing of Personal Data subject to the EU or UK GDPR unless the parties have first executed the applicable instrument as an addendum to this DPA.

13. Audit and Compliance

Processor shall make available to Customer the information reasonably necessary to demonstrate compliance with this DPA. On Customer’s written request, Processor shall provide: its then-current architecture and security documentation; the Subprocessor register; and, for Customer’s own tenant, the erasure certificate and the verification query report described in Section 8.2.

Customer may, on thirty days’ written notice and no more than once in any twelve-month period, conduct an assessment of Processor’s compliance with this DPA, at Customer’s expense and during normal business hours, subject to reasonable confidentiality obligations and without access to the data of any other customer. Customer may conduct such an assessment more frequently following a security incident affecting Customer Content or where Customer has a reasonable and documented belief that Processor is not complying with this DPA.

14. Liability, Term and Governing Law

14.1 Term. This DPA takes effect on Customer’s acceptance of the Agreement and continues until the later of the termination of the Agreement and the completion of Processor’s obligations under Section 8.

14.2 Liability. Each party’s liability under this DPA, including Processor’s responsibility for Subprocessors under Section 7.4, is subject to the limitations and exclusions of liability set out in the Agreement.

14.3 Governing law. This DPA is governed by the law specified in the Agreement, and the parties submit to the jurisdiction specified in the Agreement.

14.4 Amendment. Where Customer has accepted this DPA under Section 15.1, Processor may amend it on thirty days’ notice to Customer’s registered account address to reflect a change in Applicable Privacy Law or in the Service; if an amendment materially reduces the protections afforded to Customer Content, Customer may terminate the affected Service without penalty by notice given before the amendment takes effect. Where Customer has executed this DPA under Section 15.2, no amendment takes effect without Customer’s written agreement, save that Processor may on thirty days’ notice make an amendment strictly necessary to comply with a change in Applicable Privacy Law.

14.5 Notices. Any notice, request, objection or acknowledgement under this DPA is given in writing to the address stated for the receiving party in Section 2, and takes effect on the day of transmission if sent on a business day, and otherwise on the next business day. Customer is responsible for keeping its registered account email address current.

14.6 Severability. If any provision of this DPA is held unenforceable, the remaining provisions remain in full force.

15. Acceptance and Execution

This DPA is accepted in one of two ways, according to the Service Tier. Both create a binding agreement on identical terms; they differ only in how acceptance is recorded.

15.1 Acceptance on sign-up — free and shared_anon tiers

Customer accepts this DPA electronically at sign-up, by taking the affirmative action the Service presents for that purpose, having been given the opportunity to review this DPA in full beforehand. No signature is required.

The Service records that acceptance in its append-only consent record, capturing the identity of the accepting user, the time of acceptance, and the version of this DPA accepted. That record is the evidence of the agreement between the parties, and Processor shall make Customer’s own record available to Customer on request under Section 13.

Where this DPA is accepted under this Section, the Order Form arrangements referred to in Sections 3.4(b) and 12.5 are not available, and Customer’s rights and obligations are those stated in this DPA as published.

15.2 Execution by signature — private tier

Customer on the private Service Tier executes this DPA by signature. It may be executed in counterparts, and by electronic signature, each of which is an original and which together constitute one agreement. Execution may be recorded in or annexed to the Order Form.

15.3 Authority

Each person accepting or executing this DPA warrants that they are authorised to bind the party on whose behalf they act. Where an individual accepts under Section 15.1 on behalf of an entity, this DPA binds that entity.

15.4 Version

This DPA is versioned. The version accepted or executed by Customer governs the relationship between the parties until it is amended under Section 14.4 or replaced by a later version Customer accepts or executes. Processor maintains the current and superseded versions at https://fronset.ai/legal/dpa-versions/ .

15.5 Order of precedence

Where the parties have executed a negotiated data processing agreement, that agreement prevails over this DPA to the extent of any inconsistency. Otherwise this DPA prevails over the Agreement in respect of the processing of Customer Content, as stated in the preamble.

Annex A — Processing Summary

Annex B — Subprocessors

The Subprocessor register in Section 7.1, together with the classification of Model Providers in Sections 7.2 (accessed with Customer’s credentials — not Subprocessors), 7.2A (operator-supplied serving, accessed with Processor’s credentials — Subprocessors) and 7.3 (free-tier replay, accessed with Processor’s credentials — Subprocessors). The current register is published at https://fronset.ai/legal/subprocessors/ .

Signatures

This block applies only where this DPA is executed by signature under Section 15.2. On the free and shared_anon Service Tiers this DPA is accepted under Section 15.1 and is binding without signature; the block below is left unexecuted and the consent record is the evidence of acceptance.

KAPUA LABS LLC, DOING BUSINESS AS FRONSET

By: ______________________ Name: ______________________ Title: ______________________ Date: ____________

CUSTOMER

Entity: ______________________________________

By: ______________________ Name: ______________________ Title: ______________________ Date: ____________

Service Tier: private · DPA version: 2026-09-15