Security Questionnaire

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

This page is our canonical answer source for CSA CAIQ, Shared Assessments SIG-Lite, HECVAT, and the custom RFP security sections we see most often. If a question you need is not here, email [email protected] and we will answer it and add it for the next reviewer.

Start reading Ask a new question

How to use this

What you get, what you do not.

This document is the canonical answer source. The evidence behind each answer is cross-referenced in our controls evidence map. Items called out as Pending are tracked in our internal security roadmap and a customer-facing 12-month security plan; when asked about them in a prospect call we name the target close date rather than claim them as in-place.

For a question this page does not cover, please email [email protected]. We answer once, publish here, and the next reviewer benefits.

1. Certifications and audits

Where we are with formal attestations.

Are you SOC 2 Type II compliant?

Not yet. Type I is targeted for issuance in Q4 2026; Type II, which requires an observation period, targets Q2 2027. The audit firm and readiness platform are being selected, and we share the readiness roadmap and the current auditor relationship under NDA. One thing we want to say plainly rather than let you infer it: self-hosting does not make a SOC 2 on Sparcle irrelevant. It changes which scope matters. There is no Sparcle-hosted store of your data for an auditor to examine, but we do write, review, build, sign and ship the software that runs inside your perimeter, and we operate the update channel it trusts. A compromised build, a stolen signing key, an unpatched dependency or a careless support workflow are all real routes into your environment, and those are exactly the controls a Type II tests over time. So treat the engineering and release controls described elsewhere on this page as the interim answer, not as a reason the audit does not apply.

ISO 27001?

Not pursued in Year 1. Will reassess when EU and APAC enterprise demand warrants. Most of our customers find SOC 2 Type II sufficient.

HIPAA compliance?

We are HIPAA-aware in the bolt-api architecture (PHI handling, audit logging, crypto-shred for right-to-erasure, transmission security via TLS, BAA-able sub-processors). A formal Business Associate Agreement is executable per customer. Anthropic BAA is in progress for customers using the Claude API path. HITRUST certification is on the long-term roadmap, not in flight.

FedRAMP, PCI-DSS, FISMA?

Not pursued in Year 1. Will reassess when federal, payment, or defense customer demand warrants.

When did you last conduct a third-party penetration test?

Pending. First annual third-party penetration test is targeted for Q4 2026. Internal hardening run completed mid-2026; remediation backlog is published internally and informs scope.

2. Encryption

At rest, in transit, and the key-management surface.

How is data encrypted at rest?

Layered encryption. Application layer: AES-256-GCM envelope encryption with per-tenant Customer Master Keys (CMK). Master key sourced from a pluggable KMS backend behind the aeira-traits Kms trait. Local file-backed is production-tested today (pilots, dev, air-gap). AWS KMS and HashiCorp Vault Transit reference implementations live in the aeira-rs trait library; cloud-service integration testing is in flight. PKCS#11 HSM, Azure Key Vault, and GCP KMS reference implementations are on the roadmap; customers needing these should ask. 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.

How is data encrypted at rest on a desktop endpoint?

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 whose keys derive from a device key held in the OS keychain and gated by the user's login. Connector credentials and OAuth tokens are encrypted with AES-256-GCM. 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, entity names, timestamps) 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. Every file is mode 0600 or 0700 under the user's own account. 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.

How is data encrypted in transit?

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.

What encryption algorithms are used?

AES-256-GCM (envelope encryption); Ed25519 (audit chain signing, manifest-bundle signing); HMAC-SHA256 (PII pseudonymization, webhook signatures); SHA-256 (content hashing). Algorithms are FIPS-eligible; FIPS 140-3 module validation is pending and on the roadmap.

How are encryption keys managed and rotated?

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).

3. Access control

Identity, authorization, and privileged access.

How do users authenticate?

OIDC or SAML 2.0 via the customer's IdP (Okta, Microsoft Entra ID, Google Workspace, Auth0, Keycloak, custom). SCIM 2.0 server at /scim/v2/* for IdP-driven user provisioning (the standard SCIM mount point your IdP will look for). Per-org SCIM bearer tokens issued via the admin API; rotation recommended every 90 days (SOC 2 CC6.1, ISO 27001 A.9.4).

Multi-factor authentication?

MFA is enforced at the customer's IdP. Bolt accepts whatever authentication assertion the IdP issues. The recommended IdP configuration requires MFA for all users with admin role.

Role-based access control?

Yes. RBAC enforced at multiple layers: session middleware, admin-only middleware, OAuth scope middleware, per-tenant ACL pre-filter in Aeira's search layer. Admin role is required for KMS rotation, audit seal, PII reveal, SCIM token management.

Privileged access management?

Admin endpoints can be additionally restricted at the ingress layer by source-IP allow-list or mTLS. PII reveal is admin-gated and emits a high-risk audit event on every call; the call is permanently sealed in the Merkle chain.

How are agent and tool capabilities provisioned and restricted?

Two layers, and it helps to keep them apart. Apps and utilities are declared in YAML manifests (a recognize block plus a transform pipeline, MCP-native where they call a tool). That is the surface admins author and provision org-wide; users can build their own desktop Apps, and where the two overlap, admin-provisioned Apps take precedence. The capability set itself is not YAML: it is a fixed list compiled into the server, so no manifest edit can invent a new capability or widen an existing one. Enforcement is server-side and on by default across session middleware, admin-only middleware, OAuth scope checks, a per-tool capability check in the agent loop, and Aeira's per-tenant SQL ACL pre-filter. On top of that sits an optional policy decision point for rule-based capability policy; it ships in the box but is inert under the default governance profile, so a deployment that wants it turns it on deliberately and we walk through that configuration during a pilot. Most launcher actions are deterministic and never invoke an agent or a model at all.

4. Audit logging

What we log, how it is sealed, and where it goes.

Do you log security events?

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.

What events are logged?

Authentication events, authorization decisions, admin actions (KMS rotation, PII reveal, audit seal, SCIM token issuance and revoke), Aeira search on every exit path (denied, router-allowed, and keyword-allowed alike, sealed into the Merkle chain), tool executions, LLM calls, errors, state-machine transitions on agent runs. Aeira search cannot serve a result it did not record: the same Postgres that wires the audit sink is required to run a search at all, so the failure mode is a 503, not a silent unaudited answer. Where the coverage stops today: Aeira's catalog routes (browse, entity, graph, kinds) and Bolt's own connector-side search endpoints return results without emitting an audit event. Routing both through the same emit chokepoint is in flight, and I would rather you hear that from me than find it in a log review. Audit lines tagged with event_type=security for SIEM-side index separation.

Is the audit log tamper-evident?

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).

How long are logs retained?

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.

5. Incident response

Plan, classification, and notification SLAs.

Do you have a documented incident-response plan?

Yes. Sparcle runs a documented five-phase incident-response plan (detect, triage, stabilize, mitigate, validate-and-communicate) covering software-vendor-side incidents: a CVE in a shipped Bolt or Aeira release, a cosign signing-key or build-pipeline compromise, a sub-processor breach in our delivery chain. SEV1-4 classification with acknowledgement and patch SLAs published on /trust/incident-response and binding at every stage. A maturation path on the same page documents how coverage tiers activate with customer contracts. The deeper runbook is shared under NDA during pilot evaluation. Customer-instance incidents in the customer's own deployment are run by the customer's IR; Sparcle supports those with advisories, patches, and direct technical assistance.

What is your breach notification SLA?

Notification cadence is codified in the executed MSA, BAA, or DPA and takes precedence over the public defaults on /trust/incident-response. HIPAA breach notification (60 days per 45 CFR 164.404) and GDPR breach notification (72 hours per Art. 33) bind Sparcle for vendor-side scenarios (a CVE in our shipped software, a signing-key compromise, a sub-processor breach affecting our delivery chain). Customer-side incidents in the customer's own deployment fall under the customer's own BAAs and DPAs with their LLM, cloud, and IdP providers.

Have you experienced a security incident in the past 12 months?

No production incidents involving customer data have occurred. Internal-only incidents (build pipeline regressions, dev environment issues) are tracked separately and not customer-affecting.

6. Sub-processors and data flow

Where customer data lives.

Who are your sub-processors?

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.

Where is customer data stored?

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.

Do you transfer data internationally?

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).

7. Vulnerability management

Scanning, patching, and disclosure.

How do you handle vulnerabilities in dependencies?

Dependency scanning runs in CI on every push across all components, but enforcement differs by component and we would rather you know that than discover it. The server image is fully gated: cargo audit and cargo deny run on every push, and the image build pipeline gates on Trivy CRITICAL and HIGH findings with exit-code 1, so a failing scan blocks the push and cosign signing never runs on an image that did not pass. SBOM is emitted per build (CycloneDX) on that path. On the desktop client, two components currently report findings without blocking the build while we work down a dependency-upgrade backlog that requires semver-major bumps; enforcement gating is scheduled to follow, and we have chosen not to suppress findings to reach green faster. Customers can scan independently with their own tooling against the published SBOM. UPDATE, 2026-08: the desktop path is no longer report-only. A two-tier gate now runs a sub-second secret scan of the staged diff on every commit, and at release, against a frozen build point, scans the whole tree for secrets, Rust advisories, npm advisories across the production dependency graph, and licence obligations, with CVSS base scores computed from each advisory’s own vector. Every check reports pass, fail or unknown, so a scanner that could not run is never recorded as a scanner that found nothing.

Patch SLA?

CRITICAL: 7 days. HIGH: 30 days. MEDIUM: 90 days. LOW: next quarterly release. Patches ship as new container image tags signed with cosign.

Do you have a vulnerability disclosure policy?

Yes. See the Vulnerability Disclosure page on this Trust Center. One-business-day acknowledgement, 7-30-90 day patch SLA, 90-day coordinated disclosure, good-faith safe harbor.

8. Business continuity and disaster recovery

RTO, RPO, and failover.

RTO and RPO?

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.

How often do you test backups?

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. Sparcle's CI environment runs a backup-restore test on every release.

Multi-region failover?

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.

9. Personnel security

Background checks, training, and confidentiality.

Background checks on engineering staff?

Pending. Background check policy and vendor adoption are in the Q3 2026 timeline.

Security training?

Pending. Annual security awareness training is in the Q3 2026 timeline.

Confidentiality agreements?

All Sparcle personnel sign confidentiality and IP-assignment agreements as a condition of engagement. Sub-processors are bound by their own agreements and sub-processor commitments.

10. Software supply chain

Signing, SBOM, and SLSA.

Are images signed?

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.

Is the desktop application signed, and is it the same chain as the images?

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.

Do you provide SBOMs?

Yes. CycloneDX JSON published per release and embedded as an attestation on every image (verifiable via cosign verify-attestation type spdx).

SLSA level?

SLSA v1.0 Build L2 today (signed provenance via GitHub-issued attestation, isolated builder via GitHub Actions hosted runner). Build L3 (hermetic builds, additional non-falsifiability) is on the roadmap once we move off shared GitHub-hosted runners.

11. AI and LLM-specific questions

How prompts and PII flow at the LLM boundary.

Do you send our data to OpenAI, Anthropic, or other LLM providers?

Only the data flowing through agents the customer configures, to the LLM provider the customer configures. Sparcle does not see this data. PII is pseudonymized at the LLM-call boundary by default (HMAC tokens replace detected PII before the prompt reaches the LLM provider; original values are restored in the response).

Can I use my own LLM?

Yes. Configure APP__LLM__BASE_URL, APP__LLM__API_KEY, and APP__LLM__MODEL to point at any OpenAI-compatible endpoint (self-hosted Ollama, vLLM, Azure OpenAI, customer's BYO LLM).

Is the PII detection comprehensive?

Regex-based detection covers 10+ PII types out of the box (email, phone, SSN, credit card, US passport, US driver license, and others), and it is the always-on floor. Regex alone cannot see free-text PHI: names without format anchors, clinical notes, non-US identifiers. For that there is now a named-entity model, and the honest detail matters. On Apple Silicon Macs it is bundled and runs in-process in the same binary, with no Python service and no network call, so an air-gapped deployment needs nothing extra. On Windows, Linux and Intel Macs the shipped build does not include it and it runs as a separate scanner you deploy. In every case it is off until an administrator turns it on, deliberately, so nothing silently loads a model or changes masking behaviour on upgrade. If you enable it on a build that cannot run it, the admin API reports the engine as degraded and names the engine actually in effect rather than quietly doing nothing. Customers can supply additional regex patterns per tier.

Is the LLM output filtered?

Yes. PII is pseudonymized before LLM call; on LLM response, tokens are restored to original values for display to the user (audit-logged on restoration). Output filtering against jailbreaks and prompt-injection responses runs in the security pipeline.

Question we did not answer here?

Version 0.2. Counsel review pending. We answer once, publish here, and the next reviewer benefits.

Email [email protected] Back to Trust Center