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.

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 only Sparcle's own business operations, 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 Zoho Mail Sparcle team email · never customer data Google Workspace internal documents · never customer data deliver container images Helm charts · advisories no customer data no telemetry · no phone-home Outside the customer perimeter. Business operations 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.

Deployment topology, the customer data path in each, and Sparcle's role.
TopologyCustomer data pathSparcle'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 BoltNot 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.

Sub-processors the customer configures inside their own Bolt deployment.
Sub-processorTypical providersPurposeCustomer action
Large Language Model APIAnthropic (Claude), OpenAI (GPT), Azure OpenAI, AWS Bedrock, Google Vertex, Ollama (self-hosted), vLLM (self-hosted), and othersGenerates LLM completions from masked promptsCustomer signs DPA or BAA directly with chosen LLM provider. Anthropic, OpenAI, and the major cloud providers all offer BAAs for HIPAA.
Identity ProviderGoogle Workspace, Microsoft Entra ID, Okta, Auth0, Keycloak, AWS IAM Identity Center, custom OIDC or SAMLAuthenticates users; provides directory data via SCIMCustomer-owned IdP relationship.
Cloud ComputeAWS, Azure, GCP, on-premises Kubernetes, private cloudHosts the customer's bolt-api pods and managed Postgres and RedisCustomer-owned cloud account.
Managed DatabaseRDS, Cloud SQL, Aurora, Azure Database, on-prem PostgresStores audit logs, sessions, encrypted MCP tokens, encrypted PII vaultCustomer-owned, customer-encrypted at rest.
Managed CacheElastiCache, Memorystore, Azure Cache, on-prem RedisSession ephemera; PII tokenization map for in-flight requestsCustomer-owned.
Object Storage (optional)S3, GCS, Azure BlobBackup target and audit-chain WORM archiveCustomer-owned, customer-encrypted.
MCP IntegrationsCustomer-chosen (Jira, Salesforce, Slack, GitHub, internal services)Tool execution endpoints the customer's agents callCustomer-owned credentials; OAuth tokens stored encrypted in the customer's bolt-api Postgres.
SIEM or LoggingSplunk, Sentinel, Datadog, Elastic, customer-deployed forwarderReceives bolt-api stdout JSON for retentionCustomer-owned SIEM relationship.
KMSLocal 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.Wraps per-tenant Customer Master KeysCustomer-owned; Sparcle has no access.

Sub-processors of Sparcle

Sparcle's own business operations only.

Bolt processes no customer data on Sparcle infrastructure. The vendors below handle only Sparcle's own business operations (contact details, support email and internal documents).

Sparcle's own sub-processors, used for Sparcle's own business operations.
Sub-processorPurposeData processedLocation
GitHub, Inc. (Microsoft)Source code hosting, container registry (GHCR), CI / CDSparcle source code; published container images; build telemetryUnited States (with global edge)
Anthropic, PBCLLM API used internally by Sparcle engineers to author and review code (NOT in customer data path)Sparcle's own development queries; never customer dataUnited States
Cloudflare, Inc.DNS, domain registration, marketing-site hosting (Cloudflare Pages), DDoS and bot protection, edge functions for the contact formDNS records, marketing-site requests, contact-form submissionsUnited States (with global edge)
Zoho Mail (Zoho Corporation)Sparcle internal emailSparcle internal correspondence; never customer dataUnited States (zoho.com US data centre)
Google Workspace (Google LLC)Internal document collaboration (Docs, Drive)Sparcle internal documents; never customer dataUnited States
Accounting, payroll, business operationsTo be disclosed on first contract requiring it. Anticipated providers include Mercury, Gusto, and Stripe.Sparcle's own financial and employment recordsUnited States

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. A planned change of Sparcle's email provider will be announced the same way, by updating that table when the change is 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.

Cross-border transfer mechanisms, by jurisdiction.
JurisdictionMechanism
EU and UKEU Standard Contractual Clauses (2021/914) plus UK IDTA addendum where applicable.
SwitzerlandSwiss-FADP-equivalent SCCs.
United States (HIPAA)BAA where applicable. (We do not hold a SOC 2 Type II report today.)
CanadaPIPEDA-compliant data-handling commitments.
Other jurisdictionsCase-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.