Visca

Legal · v0.1 draft

Subprocessors

A self-hosted deployment is designed so that few or no subprocessors ever touch Customer Data. This page lists the subprocessors Visca engages to operate managed Visca Cloud, the function each performs, and how we notify customers of changes.

Last updated 2026-05-28Effective 2026-05-28

1. About this list

A subprocessor is a third party that processes Customer Data on Visca's behalf in the course of delivering the Services. Because the entire Visca stack is built to run inside the customer's own perimeter, the number of subprocessors that ever touch Customer Data is small by design — and on a fully self-managed or air-gapped deployment, it can be none. The list below applies to managed Visca Cloud, where Visca operates infrastructure on the customer's behalf. This page is the authoritative, current list referenced by our Privacy Policy and Security Policy.

Status, v0.1: Visca Cloud is pre–general availability. The list below reflects the infrastructure and operational vendors engaged for the current stage of the platform. It will expand as the Services reach production scale; every addition is published here before it begins processing Customer Data.

2. Sovereign and self-managed deployments

On dedicated, self-managed, or air-gapped deployments the stack operates entirely inside the customer's own boundary, so the subprocessor list is reduced or empty: nothing in the table below is required for the stack to run. This is the point of self-hosting, not an exception to it. The applicable subprocessor list for a specific deployment is documented in that customer's order form and Data Processing Addendum, and takes precedence over this general list.

3. Infrastructure subprocessors

  • Cloud infrastructure provider(s) — compute, storage, and networking for managed Visca Cloud tenants, in the region the customer selects. Processes Customer Data at rest and in transit within the selected region.
  • Content delivery and edge network — serves the marketing site and static assets; terminates TLS for managed endpoints. Processes request metadata, not Customer Data content.
  • Managed database and object storage — backing store for the Cast state backend and the Chronicle audit store on managed tenants. Processes Customer Data at rest in the selected region.

4. Operational subprocessors

  • Error and performance monitoring — application telemetry for reliability. Configured to exclude Customer Data payloads; processes operational metadata only.
  • Email and customer communication — transactional email, support correspondence, and account notifications. Processes contact details and message content.
  • Identity and access (for the Visca tenant) — authentication for customer administrators accessing the Visca Cloud control plane. Processes administrator identity attributes.

5. Model and inference providers

Visca does not itself send Customer Data to model providers. Inference routing is configured by the customer: the models and providers an agent may reach are declared in the customer's Cast plan and brokered through Warrant. Any model provider a customer enables is a subprocessor of that customer's choosing, governed by the customer's own agreement with that provider. Visca records — but does not retain the content of — each inference call in Chronicle.

6. Change notification

Material changes to this subprocessor list — the addition of a new subprocessor that will process Customer Data, or a change in the category of data a subprocessor handles — are communicated to affected customers in advance, with a meaningful objection period as set out in the Data Processing Addendum. Customers may subscribe to change notifications by contacting [email protected].

7. Questions

For a deployment-specific subprocessor list, a copy of the Data Processing Addendum, or any question about how Customer Data is processed, contact [email protected] or [email protected].