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 commit-pinned CycloneDX SBOM is generated on the machine that builds the release and attached to it. Every dependency in the artifact you install is enumerated, at the exact commit it was built from. Ask and we will point you at the one for the version you are evaluating.

Independent scan lookup, per release

Every release carries a VIRUSTOTAL.md listing a third-party report link for each published binary, 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.

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

Dependencies are gated by a checked-in policy file in every Rust workspace, covering licences, advisories, and banned crates. A third-party licence report ships alongside the SBOM.

Tamper-evident audit chain, verifiable offline

Every governance decision is 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.

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.

Every change is reviewed adversarially

Before a branch is allowed to land, an automated review pass reads the diff looking for defects the compiler cannot see, and reports them for the author to answer. It is run as a gate, not a suggestion.

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 a claim we cannot defend against live code reappears anywhere in it. Each banned claim cites the code that makes it false. Marketing accuracy is enforced by CI, not by memory.

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 refuses to run un-audited

If the tamper-evident audit sink is unavailable at start-up, the server refuses to boot rather than running with governance events going nowhere.

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 yet

Signed provenance, a cryptographic claim that a specific automated workflow produced a specific artifact, depends on an identity a build service issues. Releases are currently built on our own machines, and a machine cannot meaningfully make that claim about itself. 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 →