Sub-Processor Disclosure

Customer data does not reach Sparcle infrastructure.

This disclosure satisfies the sub-processor transparency requirements in GDPR Art. 28, CCPA / CPRA, Quebec Law 25, PIPEDA, Singapore PDPA, UAE Federal Decree-Law No. 45 of 2021, and equivalent regimes. The asymmetric structure below reflects the operative reality: in every shipping topology, customer data is processed in the customer's own infrastructure by services the customer has selected.

Sub-processor questions Back to Trust Center

At a glance

The asymmetric topology, visualized.

Customer data is processed by sub-processors the customer configures, inside the customer's perimeter. Sparcle's own sub-processors handle software delivery, not customer data. The two sets do not touch — and the only flow that crosses the boundary is from Sparcle outward, in the form of container images, Helm charts, and advisories.

Sub-processor topology — Sparcle is not in the customer data path The customer perimeter contains every sub-processor that touches customer data: identity provider, cloud compute, managed Postgres and Redis, object storage, LLM provider, KMS, MCP integrations, and SIEM. Sparcle sits outside the perimeter as a software vendor with its own sub-processors that handle source delivery and corporate operations only. The only flow that crosses the boundary is one-way from Sparcle to the customer perimeter: container images, Helm charts, and security advisories. Customer data never flows back to Sparcle. CUSTOMER PERIMETER · CUSTOMER-CONFIGURED SUB-PROCESSORS Identity provider Entra · Okta · Workspace Zoho · OIDC · SAML Cloud compute AWS · Azure · GCP on-prem k8s · private cloud Object storage S3 · GCS · Azure Blob backup · WORM archive Managed Postgres RDS · Cloud SQL · Aurora audit · sessions · PII vault Managed cache ElastiCache · Memorystore session ephemera MCP integrations Jira · Slack · GitHub customer-chosen tools LLM provider (BYO) OpenAI · Anthropic · Bedrock customer-held BAA / DPA KMS AWS KMS · Vault · HSM customer keys, Sparcle has no access SIEM / logging Splunk · Sentinel · Datadog customer-deployed forwarder Customer-owned credentials. Customer-held contracts. Sparcle has no access. SPARCLE — SOFTWARE VENDOR Sparcle's own sub-processors: GitHub (source + GHCR) code · container images · CI/CD Cloudflare DNS · marketing site · contact form Anthropic (internal dev only) code authoring · never customer data Google Workspace Sparcle team email · never customer data deliver container images Helm charts · advisories no customer data no telemetry · no phone-home Outside the customer perimeter. Software delivery only.

Scope

Who this disclosure is for.

This disclosure covers data-processing roles in Sparcle's standard deployment topologies. It is required reading for any customer subject to GDPR Art. 28, CCPA or CPRA, Quebec Law 25, PIPEDA, Singapore PDPA, UAE Federal Decree-Law No. 45 of 2021, or equivalent personal-data legislation.

If your contract requires Sparcle to use only sub-processors that you have approved in writing, this list is the starting point for that approval process.

Deployment topology

Topology determines who processes what.

Sparcle's role under data-protection law depends on which deployment topology you operate. In every shipping topology, customer data does not reach Sparcle-controlled infrastructure.

Topology
Customer data path
Sparcle's role
Single-user (sidecar or desktop)
All data stays on the end-user's machine. No network egress to Sparcle.
Sparcle is not a data processor.
Production (Helm in customer infra)
All data stays inside the customer's Kubernetes cluster. The bolt-api binary runs on customer compute, reads from customer-provided Postgres and Redis, and calls customer-configured LLM endpoints.
Sparcle is not a data processor for customer data. Sparcle is the software vendor.
Hosted Bolt
Not applicable. Sparcle does not offer hosted Bolt today.
Not applicable.

Sub-processors of the customer

Configured by you, inside your environment.

These are services the customer configures inside their Bolt deployment. They process customer data only because the customer points Bolt at them. Sparcle does not select them, hold credentials for them, or have access to them.

Large Language Model API

Typical providers
Anthropic (Claude), OpenAI (GPT), Azure OpenAI, AWS Bedrock, Google Vertex, Ollama (self-hosted), vLLM (self-hosted), and others
Purpose
Generates LLM completions from masked prompts
Customer action
Customer signs DPA or BAA directly with chosen LLM provider. Anthropic, OpenAI, and the major cloud providers all offer BAAs for HIPAA.

Identity Provider

Typical providers
Google Workspace, Microsoft Entra ID, Okta, Auth0, Keycloak, AWS IAM Identity Center, custom OIDC or SAML
Purpose
Authenticates users; provides directory data via SCIM
Customer action
Customer-owned IdP relationship.

Cloud Compute

Typical providers
AWS, Azure, GCP, on-premises Kubernetes, private cloud
Purpose
Hosts the customer's bolt-api pods and managed Postgres and Redis
Customer action
Customer-owned cloud account.

Managed Database

Typical providers
RDS, Cloud SQL, Aurora, Azure Database, on-prem Postgres
Purpose
Stores audit logs, sessions, encrypted MCP tokens, encrypted PII vault
Customer action
Customer-owned, customer-encrypted at rest.

Managed Cache

Typical providers
ElastiCache, Memorystore, Azure Cache, on-prem Redis
Purpose
Session ephemera; PII tokenization map for in-flight requests
Customer action
Customer-owned.

Object Storage (optional)

Typical providers
S3, GCS, Azure Blob
Purpose
Backup target and audit-chain WORM archive
Customer action
Customer-owned, customer-encrypted.

MCP Integrations

Typical providers
Customer-chosen (Jira, Salesforce, Slack, GitHub, internal services)
Purpose
Tool execution endpoints the customer's agents call
Customer action
Customer-owned credentials; OAuth tokens stored encrypted in the customer's bolt-api Postgres.

SIEM or Logging

Typical providers
Splunk, Sentinel, Datadog, Elastic, customer-deployed forwarder
Purpose
Receives bolt-api stdout JSON for retention
Customer action
Customer-owned SIEM relationship.

KMS

Typical providers
Local file-backed (production-tested; pilots, dev, air-gap). AWS KMS and HashiCorp Vault Transit reference implementations in the aeira-rs trait library; cloud-service integration testing in flight. PKCS#11 HSM, Azure Key Vault, and GCP KMS reference implementations on the roadmap.
Purpose
Wraps per-tenant Customer Master Keys
Customer action
Customer-owned; Sparcle has no access.

Sub-processors of Sparcle

For software delivery only.

These are Sparcle's own sub-processors. They handle Sparcle's software-delivery operations, not customer data.

GitHub, Inc. (Microsoft)

United States (with global edge)
Purpose
Source code hosting, container registry (GHCR), CI / CD
Data processed
Sparcle source code; published container images; build telemetry

Anthropic, PBC

United States
Purpose
LLM API used internally by Sparcle engineers to author and review code (NOT in customer data path)
Data processed
Sparcle's own development queries; never customer data

Cloudflare, Inc.

United States (with global edge)
Purpose
DNS, domain registration, marketing-site hosting (Cloudflare Pages), DDoS and bot protection, edge functions for the contact form
Data processed
DNS records, marketing-site requests, contact-form submissions

Google Workspace

United States
Purpose
Sparcle internal email and document collaboration
Data processed
Sparcle internal correspondence; never customer data

Accounting, payroll, business operations

United States
Purpose
To be disclosed on first contract requiring it. Anticipated providers include Mercury, Gusto, and Stripe.
Data processed
Sparcle's own financial and employment records

What Sparcle does not do

The boundary, stated plainly.

  • Operate a multi-tenant hosted version of Bolt for production customers.
  • Hold customer encryption keys, KMS material, or PII master values.
  • Process customer audit logs on Sparcle-controlled infrastructure.
  • Access customer Postgres, Redis, or LLM-provider API keys.
  • Receive telemetry, analytics, or usage data from production customer installations (no phone-home; verifiable via NetworkPolicy egress deny).
  • Sub-process any customer data via affiliates, contractors, or acquirers without prior notice and the customer's right-to-object.

Notice of changes

30-day advance notice for sub-processor changes.

Sparcle will notify the customer (via the email on file with the account) at least 30 calendar days before adding or replacing a sub-processor that handles customer data. The customer has the right to object in writing within that window; if Sparcle cannot reasonably accommodate the objection, the customer may terminate the affected service for cause.

For sub-processors that handle only Sparcle's own internal data (the Sub-processors of Sparcle table above), no advance notice is required. That table is refreshed when changes are made.

Customers who want active notification can subscribe by emailing [email protected] with the subject line "subprocessor notifications".

Cross-border transfers

Mechanisms we rely on.

When sub-processors operate outside the customer's data-residency jurisdiction, Sparcle relies on the following transfer mechanisms.

Jurisdiction
Mechanism
EU and UK
EU Standard Contractual Clauses (2021/914) plus UK IDTA addendum where applicable.
Switzerland
Swiss-FADP-equivalent SCCs.
United States (HIPAA)
BAA where applicable. (SOC 2 Type II targeted Q2 2027.)
Canada
PIPEDA-compliant data-handling commitments.
Other jurisdictions
Case-by-case. Contact [email protected].

Questions about a specific sub-processor or transfer mechanism?

Version 0.2. Counsel review pending; this page is updated on any material change.

[email protected] [email protected] (contract)