Trust Center

Resources

Public pages open right away. Items with a lock are shared under a mutual NDA during evaluation.

For your IT team

  • One page to forward to whoever has to approve Bolt: vendor identity, exactly what leaves the endpoint, every permission and what happens if it is denied, storage and encryption, code signing, current assurance status including what we do not have, and managed deployment. Written for the reviewer rather than for the buyer.

  • What Google's “Access blocked: your institution's admin needs to review Bolt by Sparcle” screen means, and the two ways past it: run Bolt on an OAuth client you own so it is first-party inside your own tenant, or allowlist Sparcle's client IDs in the Admin console. Publishes both client IDs, every scope Bolt requests and what each one cannot do, and a request block an administrator can decide on without a call.

  • One page per identity provider, written for the administrator who has to do the work: Okta, Microsoft Entra ID, Google Workspace, Auth0, Zoho, and any OIDC provider. Creating the application, giving Bolt the credentials, the four separate levers that grant access, what Bolt is able to read, and rolling the desktop app onto laptops.

  • An OIDC web application against the org authorization server, or SAML if you standardise on it. Access is gated by app assignment, and group membership reaches Bolt over SCIM Push Groups.

  • An app registration with the authorization code grant, access gated through Enterprise applications, and group membership read from Microsoft Graph at login.

  • An internal OAuth client, login restricted to your domain, and group membership read from the Directory API at login.

  • A regular web application, with access gated by an Organization or by an Action, and group membership carried over SCIM.

  • A server-based client in the Zoho API Console, with the datacenter matching the region your org lives in, and groups read from Zoho Directory at login.

  • Ping, Keycloak, JumpCloud, OneLogin, or anything else that is OIDC compliant. Point Bolt at the issuer and it discovers the rest.

Assurance

  • What is architecturally deployable today (HIPAA, SOX, ITAR, GDPR, FCA, DORA), and which certifications we do not hold yet. Honest framing throughout.

  • Bolt was assessed by an authorized third-party lab against the 48 requirements of Google's CASA programme, and Google granted restricted access to Gmail data on the strength of it. States plainly what the assessment covers, what it proves, and what it does not: it is not a penetration test and it is not SOC 2.

  • Pre-filled answers to the security questions every procurement team asks. Encryption, access control, audit, sub-processors, incident response, supply chain. Saves your team a 20-hour vendor intake.

  • Maps SOC 2 Trust Services Criteria, HIPAA Security Rule, GDPR articles, and ISO 27001 Annex A controls to concrete evidence in our codebase and runbook.

AI and data handling

  • How Bolt's extensible, governed agentic platform and Aeira's data plane fit together: agentic and deterministic, with most queries never touching a model. Identity-bound retrieval, multi-layer security pipeline, customer-extensible Authority Policy SDK.

  • How Bolt's BYO LLM architecture keeps the runtime inside your perimeter regardless of where the model itself lives. The three deployment modes (on-prem inference, in-tenant cloud LLM, public vendor API), the five-tier endpoint privacy taxonomy, and the PII-masking layer that runs before every outbound LLM call.

  • Four places the product distinguishes unknown from clean: a scanner that could not run, a file part that could not be read, a detection engine that cannot run on this platform, and a release with no independent scan yet. Why a false clean is worse than a known gap, and why this is not a discipline a vendor can adopt after the fact.

  • An agent that can send mail and run commands is a different risk from a chat box. Where hostile content gets in, the four controls between a malicious document and an action, the six questions a security team actually asks, and what these controls do not cover. Written so the load-bearing parts are the ones that do not depend on recognising the attack.

Privacy and residency

  • GDPR Art. 28, CCPA, PIPEDA aligned. Distinguishes sub-processors of the customer (LLM provider, IdP, cloud) from sub-processors of Sparcle (GitHub, Cloudflare). 30-day change notification.

  • Per-tenant CMK destruction with SOX, SEC, and HIPAA retention preserved, and how one person's GDPR Art. 17 request is handled. WORM ciphertext, tamper-evident receipt. The packet your DPO or external auditor receives.

  • Most sovereignty claims are configuration statements the buyer has to take on trust. Aeira records the region that served each request inside the Merkle-sealed audit chain rather than beside it, so editing it invalidates the signature and the offline verifier refuses a bundle that claims a region its encoding does not cover. Includes the distinction most likely to be misread, between the access-control field about who may read a document and the record of where a request was handled, and states plainly what the mechanism does not prove.

Deploy and allowlist

  • How to push Bolt to a managed fleet and pin its settings: macOS configuration profiles, Windows Group Policy templates, and a browser extension that can be force-installed so users cannot remove or disable it. No browser store listing is required. Includes an honest account of what cannot be prevented.

  • A self-disclosed inventory of the local behaviour a security tool will flag, for the reviewer whose tooling judges behaviour rather than signatures: every port Bolt binds and why it binds loopback only, every OS command it can spawn and which are read-only, the permissions it holds, the local certificate authority it creates and how to remove it, where at-rest protection differs by platform, and the MITRE ATT&CK technique a SOC console will label each one with. Includes the two disclosures most likely to stop a review, the local certificate authority and the embedded PostgreSQL payload. Written so a reviewer can check each claim on their own machine rather than take it on our word.

  • The exact hostnames to allow so Bolt can be downloaded, updated, and run behind a secure web gateway, with per-vendor steps for Palo Alto, Zscaler, Cisco Umbrella, Netskope, and Fortinet. Written to be forwarded to a network admin without edits. Includes what Bolt contacts at runtime and what it never contacts.

Check it yourself

  • There is no Sparcle cloud to audit, so the assurance that matters is supply chain: a commit-pinned CycloneDX SBOM per release, independent malware scan links, signed and notarised builds, a checked-in dependency policy, and the mechanisms that gate every change we make. Includes what we do not have yet.

  • The standalone audit-chain verifier. One binary your auditor runs offline against an exported proof bundle, with no database, no KMS and no network in the path. A sample bundle and the platform public key are available pre-NDA so your security team can run it end to end before installing anything.

  • A read-only script, and the manual equivalents, that show every connection Bolt opens on your own machine and name each one against our published list. Includes a real sample run, what you should expect to see, and an honest account of what the method cannot tell you.

  • The release signing public key, and the exact commands to prove a Bolt download came from us and was not tampered with. Also states where platform trust stands: macOS builds are signed with an Apple Developer ID and notarized, Windows is signed with an EV certificate, and the page is explicit that SmartScreen can still warn.

Policies

  • How to report a security issue, our 1-business-day acknowledgement target, 90-day coordinated disclosure window, and good-faith safe harbor.

  • Our five-phase response framework, severity classification, customer notification SLAs (HIPAA 60-day, GDPR 72-hour), and contractual escalation paths.

Company

  • Eight provisional patent applications filed with the USPTO covering Bolt and Aeira: what a provisional does and does not mean, and how to get the filing detail under NDA.

On request

  • Architecture brief Request access

    Component diagrams, runtime topology, pipeline layer detail.

  • Threat model Request access

    STRIDE-by-component, mitigations mapped to controls.

  • Threat-model walkthrough with our engineers Request access

    A working session against your own deployment, not a document.

  • DPA, MSA, BAA, SLA templates Request access

    Customer-counsel-ready starting points, v0.2 pending counsel review.

  • SOC 2 readiness package Request access

    Current control posture and gap analysis ahead of formal audit.

  • Patent claim summaries Request access

    What the USPTO filings cover and how they map to the runtime.

  • Reference customer conversations Request access

    Design partners willing to take a call.

  • DPA template Request access

    Data Processing Addendum. GDPR Art. 28 aligned. SCCs and UK IDTA addendum included.

  • MSA template Request access

    Master Services Agreement. Software license, support, IP, warranty, liability, term.

  • BAA template Request access

    Business Associate Agreement. HIPAA-aligned for customers handling PHI.

  • SLA and Support template Request access

    Uptime and response targets that match the deployment topology you operate.

  • CASA assessor report Request access

    The lab's report, shared with your security team on request.

  • Penetration test report In progress, not yet available

    Testing in October 2026. The summary will be public; the full report is shared on request.

  • Operations runbook and incident workflow Request access

    The deeper runbook behind the public incident framework.

  • Disaster-recovery documentation Request access

    Named RTO and RPO values for typical topologies.

Need something not listed? Email [email protected].