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, and we are not going to put a date on it that we have not bought. We hold scoped fixed-fee quotes from audit firms and begin the engagement when a customer engagement requires one; Type II then follows its required observation period. 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.

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?

Not yet performed. We are comparing quotes from firms that publish their reports by default, and we will publish the summary when it is done. 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, 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 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. 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.

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; connector credential and OAuth token encryption); 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.

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, per-handler OAuth scope checks on the endpoints that accept bearer tokens, and a per-tenant ACL pre-filter in Aeira's search layer with no admin bypass across the tenant boundary. Admin role is required for KMS rotation and shred, PII reveal, and SCIM token management; audit seal accepts either an admin session or a bearer token carrying the audit-seal scope.

Privileged access management?

Admin endpoints can be additionally restricted at the ingress layer by source-IP allow-list or mTLS; that is your ingress configuration, not something the chart ships. PII reveal is admin-gated and sealed into the Merkle chain on every attempt, revealed or denied. The sealed record is deliberately thinner than the local log line: it carries a one-way reference to the masked token rather than the token itself, never the revealed span, and of the operator's free-text justification only whether one was given plus a stable hash of it, so the record about a disclosure does not repeat the disclosure. Two privileged actions refuse rather than proceed unevidenced: a PII reveal returns 409 if auditing has been switched off, and a crypto-shred returns 503 if no sealed audit sink exists or 409 if auditing is off, with nothing destroyed in either case. KMS rotation and SCIM token issue and revoke are sealed best-effort, because blocking a rotation or a de-provisioning during an incident is the worse failure. One gap remains and we would rather you hear it here than find it in a log review: the audit-seal operation itself still writes a log line rather than a sealed record.

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?

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.

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?

Two paths, and they are gated differently. Server image: cargo audit and cargo deny run on every push, and the image build 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. A CycloneDX SBOM is emitted per build on that path. Desktop client: a two-tier gate 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 rather than copied from a summary. Every check reports pass, fail or unknown, so a scanner that could not run is never recorded as a scanner that found nothing. Customers can scan independently with their own tooling against the published SBOM.

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

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

SLSA level?

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.

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 model-call boundary by default: HMAC tokens replace detected PII before the prompt leaves, and the original values are restored in the response. The masking is active where a detector is configured; the always-on regex floor is what provides it out of the box.

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 the model call; on the response, tokens are restored to the original values for display to the user. Output filtering runs in the security pipeline and covers a known set of jailbreak and prompt-injection phrasings, plus a failsafe that blocks a response still carrying an unrestored token. Treat pattern matching as the weaker half of the defence: it recognises phrasings it has seen, and a new one will not match. The controls we lean on are the ones that do not depend on recognising an attack, and they are set out at /trust/agent-safety.

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