Pre-filled answers to the questions every procurement team asks.

Layered, and scoped precisely. Per-tenant envelope encryption: each organization has its own Customer Master Key (CMK). A value is encrypted with AES-256-GCM under a fresh 256-bit data key, and that data key is wrapped by the tenant CMK. In Bolt's server this covers stored secrets (organization LLM API keys and the Aeira backend client secret); in Aeira it covers indexed document content and PII-vault entries. Document titles and embedding vectors stay readable so they can be searched, and audit records are signed rather than encrypted. KMS backends: local file-backed is the default and production-tested today (pilots, dev, air-gap); the tenant key is derived on your host from a host master plus a per-tenant secret, so it is operator-held on your infrastructure, not held in a cloud KMS. AWS KMS (per-tenant alias) and HashiCorp Vault Transit (per-tenant Transit key) are implemented; cloud-service integration testing is in flight. With Vault Transit, Vault encrypts the value itself, so there is no local data key and the cipher is the one configured on the Transit key. PKCS#11 HSM, Azure Key Vault, and GCP KMS are on the roadmap; customers needing these should ask. Conversation content (message bodies, agent runs, memory) is not under the CMK: it is sealed with XChaCha20-Poly1305 under a key from your secret store, and a server deployment configured without that key stores it unencrypted. OAuth and connector tokens are sealed separately (see the algorithms answer below). Database layer: customer responsibility, typically managed Postgres (RDS, Cloud SQL, Aurora) with the provider's at-rest encryption enabled. Disk layer: customer responsibility, typically the cloud provider's volume encryption or LUKS.

Different answer from the server question above, because Bolt on a laptop has no managed database and no cloud volume behind it. Measured on a current build: clipboard history, alerts, the local search index, the thumbnail cache, and the on-device vector indexes are stored in SQLCipher databases, each keyed by its own subkey derived from a single device master. Be precise about where that master lives, because it decides what the rest is worth: on a signed release build it is held in the OS keychain, AND a copy of it is retained on disk in the same data directory at mode 0600 as a recovery file that is deliberately not deleted. On a build that is not a notarized release, that file is the primary store. An attacker who can read the data directory can therefore read the databases. Connector credentials and OAuth tokens are sealed with authenticated encryption (AES-256-GCM for the sign-in refresh token that Google and Microsoft mail, calendar and file access run on; XChaCha20-Poly1305 for MCP connector credentials). Bolt also runs a local Postgres instance on loopback for chat and memory records; the heavy content of those records is sealed with authenticated encryption, while a small queryable surface (subjects, short facts, entity names, timestamps, file paths, URLs) is stored in the clear so local search works without decrypting the whole store, and the data directory itself is not separately encrypted by the application. If the per-install key cannot be saved, chat and memory bodies are stored unencrypted, with a logged warning, rather than sealed under a key that would not survive a restart. Secrets, key material and the encrypted stores are written mode 0600 with their directories at 0700 under the user's own account, and get an explicit owner-only ACL on Windows; this is applied per artifact rather than as a blanket sweep over the data directory. We recommend, and managed deployments should enforce, FileVault or BitLocker: that is what closes the lost-or-stolen-device case, and we would rather say so than imply the application layer already has.

TLS at ingress (cert-manager and Let's Encrypt or customer PKI; HSTS preload-list-eligible). TLS for Postgres connections (SSL_MODE=require recommended). TLS for Redis when supported by the managed provider. TLS for all LLM-provider API calls. mTLS optional on admin endpoints via ingress annotations.

AES-256-GCM (per-tenant envelope encryption; Google and Microsoft sign-in token and storage credential encryption); AES-256-GCM for shared files (at rest under the server master key, bound to the owning user; org-only links); XChaCha20-Poly1305 (MCP token and message content sealing, on HKDF-derived per-purpose subkeys); SQLCipher (desktop at-rest databases); Ed25519 (audit chain signing, manifest-bundle signing, update-bundle signing); RS256 (licence token verification); HMAC-SHA256 (PII pseudonymization, webhook signatures); SHA-256 (content hashing). Algorithms other than XChaCha20-Poly1305 are FIPS-eligible; FIPS 140-3 module validation is pending and on the roadmap.

Per-tenant CMK rotation via an authenticated admin endpoint. Old DEKs continue to decrypt; new writes wrap under the new key id. Customer-driven cadence (recommend annual or on suspected key compromise). Cosign signing for releases uses keyless Fulcio short-lived certs, so there is no long-lived signing key to manage. Master keys for PII pseudonymization and token vault encryption are sourced from the customer's secret store (External Secrets Operator and AWS Secrets Manager, GCP Secret Manager, or Vault).

Yes, and there are two ways to get them out. Collector path: structured JSON to stdout (set LOG_FORMAT=json; default in production overlay), which Vector, Fluent Bit, OpenTelemetry Collector, or Datadog Agent picks up like any other workload. Direct path: bolt-api ships an authenticated forwarder with backends for Splunk HEC, Microsoft Sentinel via the HMAC-signed collector API, Microsoft Sentinel via a Data Collection Rule with AAD OAuth2 and automatic token refresh, and syslog over TCP. The direct forwarder is off by default and no shipped values file turns it on, so plan it as a deployment step. It sends best-effort with no retry buffer today, so if you need guaranteed delivery under a transient SIEM outage, put a collector in front. SIEM export guide is shared during pilot evaluation.

Two different things travel under the word logging here, and the distinction is the whole answer. SEALED INTO THE MERKLE CHAIN: authorization decisions, retrieval access on every exit path, Aeira search on every exit path (denied, router-allowed and keyword-allowed alike), tool executions, model calls, agent decisions, admin policy changes, the security-relevant identity transitions (sign-in success and failure, sign-out, session delegation, delegated-session revocation, and session attach both accepted and refused), and the privileged key and identity operations (KMS rotation, crypto-shred, PII reveal, SCIM token issue and revoke). Failures are sealed alongside successes, deliberately: a chain that shows only successes cannot tell nobody-tried from somebody-tried-a-thousand-times, and a refused session attach is the exact shape of a session-fixation attempt. Aeira search cannot serve a result it did not record: the audit sink is required to run a search at all, so the failure mode is a 503 rather than a silent unaudited answer. EXCLUDED ON PURPOSE, and pinned that way by tests so the decision cannot drift: OAuth access-token refresh, which grants no new authority (same user, same session, same already-consented scopes) and fires roughly hourly per active session, and the read-only SCIM token list. Sealing those would bury the transitions that do change authority. NOT SEALED TODAY, and a gap rather than a choice: the audit-seal operation itself, which still emits only a structured log line. Also unsealed: Aeira's catalog routes (browse, entity, graph, kinds), Bolt's connector-side search endpoints, and agent-run state transitions, which are written to a run-history table rather than the chain. Audit lines are tagged event_type=security for SIEM-side index separation.

Yes. Bolt-api maintains a Merkle-sealed audit chain in Postgres. Operators (or scheduled jobs) can call an admin endpoint to roll a date range into a signed Merkle root, and verify integrity via a corresponding verify endpoint. Recommended pattern: nightly seal plus export root to write-once storage (S3 Object Lock, Azure Immutable Blob, GCS Bucket Lock).

Customer-owned retention via their SIEM or log archive. Recommended minimums by framework: SOC 2 CC7 1 year, HIPAA 164.312(b) 6 years, GDPR Art. 30 at least 1 year, SEC 17a-4 6 years (WORM), PCI-DSS 10.7 1 year with 3 months online.

See the Sub-Processor Disclosure on this Trust Center. Summary: in customer-hosted deployments (the only shipping topology), Sparcle is not a data processor. Customer data flows from customer-deployed bolt-api pods to customer-configured LLM providers, customer-managed databases, and customer-owned cloud infrastructure. Sparcle's own sub-processors handle Sparcle internal operations (source code on GitHub, etc.), not customer data.

In the customer's own infrastructure. Sparcle does not host or process customer data in any shipping topology. Verifiable by inspecting the deployed Helm chart's NetworkPolicy egress rules and by the absence of phone-home traffic.

Customer-determined. Bolt is deployed wherever the customer's Kubernetes cluster sits; LLM endpoints can be pinned to the customer's geography. Where the customer routes data to a US LLM provider from an EU jurisdiction, the customer's relationship with that LLM provider governs the Art. 44 and following transfer mechanisms (SCCs).

Customer-deployment-dependent (a single-replica customer has different recovery characteristics than a multi-region multi-replica customer). Bolt-api's backup CronJob default schedule is nightly; customers can tune. Named values for typical topologies are in the disaster-recovery documentation shared during pilot evaluation.

Backup restore drills are part of the customer's DR procedure. The chart ships the CronJob; the restore drill is the customer's operational practice. On our side the deep restore test (a full restore into a temporary database, with verification) is a maintained tooling target we run deliberately, not a step wired into a release pipeline. We would rather state that than let you assume a gate exists.

Customer-deployment-dependent. The chart supports multi-replica within a region via replicaCount, HPA, and pod anti-affinity; multi-region requires customer-side traffic-routing infrastructure.

Yes. Every image is signed via cosign keyless (Fulcio and Rekor transparency log). Verification recipe and admission policy guidance (Sigstore Policy Controller, Kyverno) are in the deployment documentation shared during pilot evaluation.

It is signed, but it is a different chain, and the distinction matters when you are assessing us. The server image chain is cosign keyless with Sigstore transparency-log verification. The macOS desktop client is signed with an Apple Developer ID certificate and notarized by Apple, the Windows installer is signed with an SSL.com EV certificate, and every auto-update bundle is separately signed with an Ed25519 key whose public half is compiled into the client, so the updater refuses any bundle it cannot verify. Every release also ships a minisign-signed SHA-256 manifest covering all of its artifacts, and the exact commands to verify a download yourself are published at /trust/verify-download, so you can confirm any of this without taking our word for it. Cosign, Trivy gating, and per-build SBOM attestation described elsewhere on this page apply to the server image path; do not assume they cover the desktop artifact.

Yes, and the two formats are not the same artifact. The image carries the builder-generated SPDX attestation, verifiable via cosign verify-attestation type spdx. The CycloneDX JSON is produced separately and published with the release. Ask for the one you need and we will point you at it for the exact version you are evaluating.

We do not claim a SLSA level, and the honest reason is on our supply-chain page: releases are built on our own machines, and a machine cannot meaningfully attest to itself. Signed build provenance needs an identity a build service issues, and that is what would move us onto the SLSA ladder. What exists today is a different and narrower thing: a Sigstore identity signature over the release manifest, recorded in a public transparency log, which proves who signed and when but not how the artifacts were produced.