Trust Center

There is no Sparcle cloud to audit. Here is what to audit instead.

Bolt runs on your own machines or inside your own network. Sparcle operates no system that receives your prompts, your documents or your data, in any deployment. That is a deliberate architectural choice, and it changes which assurance artifact is actually useful to you: the risk worth retiring is not how we run a service, because we do not run one. It is whether the software you install is the software we wrote, and whether we build it responsibly.

Trust Center → Request the artifacts for a version

The honest framing

Why a SOC 2 report on us would attest to a system that is not in your path.

A SOC 2 report describes how a service organisation operates a system on your behalf. Its entire subject is a vendor running something your data flows through. Bolt is not that: the runtime is yours, the data never leaves it, and there is no inspection endpoint we operate. If your review requires SOC 2 for every vendor regardless of architecture, tell us early and we will be straight with you about our timeline rather than consume your review cycle. Our current targets are published on the security page, without embellishment.

What we give you instead

Supply chain evidence, shipped with the release.

These are produced on the machine that actually builds each release, and attached to it. They are not a workflow that exists and never runs.

Software bill of materials, per release

A CycloneDX SBOM is generated on the machine that cuts the release and attached to it. It records each source repository at the exact commit the release was built from, and the SHA-256 of every artifact it describes. One honest limit: it is derived from the dependency lockfiles, not from the compiled artifact, and if a repository cannot be scanned it is published marked partial rather than withheld. So read it as a commit-pinned statement of what went in, not as an inventory recovered from the binary.

Independent scan lookup, per release

Every release carries a VIRUSTOTAL.md listing a third-party report link for each installer, keyed to that artifact's own SHA-256. We publish the lookup rather than a verdict of our own, because the point is that you are not relying on our word. Read the file before you read the links: each entry states whether a scan exists for those exact bytes yet, and says so plainly when one does not, rather than leaving you to click and find an empty page. It covers the installers rather than every published file, so the CLI binaries are not listed.

Signed by a verified identity, per release

Every release carries a Sigstore signature over its SHA-256 manifest, alongside the minisign one. They prove different things and both are published: minisign proves the manifest came from whoever holds our release key and verifies offline, depending on nobody. The Sigstore signature is bound to a verified identity and recorded in a public, append-only transparency log, so the fact that it was signed, by whom, and when, is a matter of public record rather than our assertion. Verification instructions are on the verify-your-download page.

Signed and notarised builds

macOS builds are code-signed and notarised by Apple. Windows builds are signed through a cloud HSM. The installers verify a SHA256 manifest, so a tampered download fails before it runs.

Dependency and vulnerability policy

Every Rust workspace carries a checked-in dependency policy covering licences, advisories and banned crates. Where it blocks rather than reports is worth stating: on two of the five workspaces the check fails the build in CI, on the other three it currently reports without blocking. The gate that does block for a shipped release is the release preflight, which refuses on any secret, any Rust advisory at CVSS 7.0 or above, any high or critical production npm advisory, and any copyleft licence in the graph.

Tamper-evident audit chain, verifiable offline

Governance decisions are sealed into an Ed25519-signed Merkle structure, and a standalone verifier re-derives and checks it with nothing from Sparcle in the loop. Your auditor can run it on an air-gapped machine. What the chain covers, and the admin actions it does not cover yet, is set out on the security questionnaire rather than rounded up here.

Vulnerability disclosure policy

A published route for reporting a security issue to us, with the response commitments that go with it.

How we build

Secure development, described as it actually works.

Not a policy document written for an auditor. These are mechanisms enforced by tooling on every change, which is why they are worth telling you about.

Every change is scanned for secrets, and every release for vulnerabilities and licences

Two tiers. On every commit, a sub-second scan of the staged diff for leaked credentials. At release, against a frozen build point, the whole tree is scanned for secrets, Rust vulnerabilities, npm vulnerabilities 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.

Every change is isolated before it is written

Work happens in an isolated branch and working tree, never directly on the shared mainline. A pre-commit guard enforces it rather than a convention asking politely.

An adversarial review pass is available on any change

An automated review reads a diff looking for defects the compiler cannot see and reports them for the author to answer. Do not read more into it than that: it is advisory by design and it does not block a landing, so it is a tool our engineers point at their own work rather than a gate every change must clear. The gate every change must clear is the compile-and-test one below.

Every change is compiled and tested by one gate

Branches are batched and the full compile and test suite runs once against the integrated result. If the batch fails, the specific breaking change is isolated and dropped, and the rest still land, so the mainline stays buildable.

Claims are gated in the build

This website fails its own build if one of a list of claims we cannot defend reappears anywhere in it, and because the deploy runs that build, a banned claim means no new site rather than a bad one. The list carries the reasoning behind each entry, and for the ones that turn on a specific behaviour, the source that makes the claim false. It catches a known claim coming back; it cannot prove a new phrasing is true, and the script says so about itself.

Security-critical logic lives in one place

Detection, masking and policy resolution are single shared libraries used by the server, the desktop app and the browser extension, rather than reimplemented per surface. A rule cannot be right in one place and wrong in another.

The product can be made to refuse to run un-audited

Set the governance profile to regulated and the server refuses to boot when the tamper-evident audit sink is unavailable, rather than running with governance events going nowhere. Say the quiet part: that profile is not the default. A default deployment missing the sink boots and logs the fact at error level. If audit is load-bearing for you, set the profile deliberately.

What we do not have yet

Stated here so you do not have to discover it.

Build provenance is not signed by a build service, so we claim no SLSA level

Signed provenance, a cryptographic claim that a specific automated workflow produced a specific artifact, depends on an identity a build service issues. Releases are cut on our own machines, and a machine cannot meaningfully make that claim about itself. We would rather say that than quote a SLSA level we cannot support. It becomes real when releases are built in a service that can attest to them, and we would rather say that than imply we have it.

This is worth separating from the identity signature described above, because the two are easy to confuse. A Sigstore signature proves who signed a manifest and when. Build provenance would prove how the artifacts were produced. We have the first and not the second.

SOC 2 and a third-party penetration test are targets, not artifacts

Both are dated on the security page. Neither exists today. A scoped external review of the security-critical libraries is the nearer-term step we think is more relevant for shipped software than a network test of infrastructure we do not operate.

Source is not public

Bolt is closed source. That is exactly why the artifacts above matter: an SBOM, a signed build, an independent scan and an offline-verifiable audit chain are how you check a closed-source product without taking our word for anything.

Send us the review, not just the questionnaire.

Tell us the specific risk your process is trying to retire and we will point you at the artifact that retires it, or tell you plainly that we do not have one yet.

Talk to us Pre-filled security questionnaire →