Architecture
Built so your security team says yes.
Bolt and Aeira are designed for the enterprises that can't compromise on either. Below is the architectural posture at the level a buyer needs to evaluate fit. Detailed component briefs, security architecture decisions, and patent-protected implementation specifics are shared under NDA during pilot evaluation.
System overview
How Bolt and Aeira fit together inside your perimeter.
The customer perimeter contains every part of the runtime that touches data. Identity flows in from your existing IdP. Bolt is the agent runtime; Aeira is the data plane. Tools attach via open MCP. Only the LLM endpoint sits outside, and which mode it runs in is your choice. Device-posture conditioning from your existing EDR (Falcon / Defender / Cortex) joins the perimeter in the next release without breaking it.
Bolt: Enterprise Agent Platform
An agent runtime built for durability and trust.
Three ways in, one policy
No API keys in anyone's hands
Multi-layer security pipeline
Bring your own models
Durable agent lifecycle
Aeira: Compliance-Grade Data Plane
The data plane your auditor signs off on.
Identity-bound access
Provable erasure
Audit-trail responses
Air-gap-ready by default
Authority Policy SDK: Customer-Extensible Layer
Your search. Your policy. Your code.
Every regulated vertical has its own honest definition of authoritative. The Authority Policy trait lets customers write theirs (in Rust, or in YAML config that wraps the reference packs) without forking the product. ACL handles authorization. Authority Policy handles ranking. Separate concerns, separate trait surfaces. Three reference packs ship in the box; vertical and customer-specific packs ship on engagement.
Default pack
Regulated pack
Healthcare pack
Customer-written
The trait surface and reference impls live in aeira-authority-policy.
Full-detail poster:
bolt-aeira-architecture-poster.pdf.
The full architectural view
Every component that ships, in one diagram.
The print-quality architecture poster, embedded below. Bolt's client surfaces on top; Aeira's three internal layers (search pipeline, storage and cryptography, ingest spine and cache); the connector catalog grouped by category; the three external integrations (your IdP, your LLM, your KMS) outside the perimeter. The Authority Policy SDK is the customer-extensible wedge, highlighted in the search pipeline.
If the embed below doesn't render in your browser, open the poster PDF in a new tab or use the download button at the bottom of this section.
Tech stack
What ships under the hood.
The runtime is Rust end-to-end. The search substrate is pluggable (keyword on Postgres FTS or Quickwit, vector on pgvector or Qdrant) selected by config, not code. The audit chain is Ed25519-signed Merkle epochs. The full list below: every layer is swappable; reference impls ship in the box.
Runtime & API
- Language
- Rust 1.85+
- Workspace
- ~160 crates
- HTTP layer
- axum · tower
- Async runtime
- tokio
- Auth
- OIDC · SAML · JWT
- Telemetry
- OpenTelemetry · Prometheus
Search & ranking
- Keyword
- Postgres FTS · Quickwit
- Vector
- pgvector · Qdrant
- Fusion
- RRF (weighted)
- Policy
- Authority Policy SDK
- ReBAC
- OpenFGA pilot
- Cache L1
- LRU
- Cache L2
- Redis pilot
Ingest & storage
- Spine
- NATS JetStream
- Storage
- FS + S3 Object Lock pilot
- KMS
- Vault · AWS KMS · PKCS#11
- Audit
- Ed25519 + Merkle
Clients
- Desktop
- Native · macOS · Linux · Windows
- Web
- Svelte 5 · installable PWA
- Browser ext
- Chrome Manifest v3
- Mobile
- iOS · Android Q3 2026+
Client security
We do not write our own cryptography.
The most common question a security reviewer asks about a desktop application is where it keeps your credentials and what it uses to protect them. Both answers are boring on purpose, and both are named here so you can check them rather than take our word for it.
Credentials live in your OS
- macOS
- Keychain
- Windows
- Credential Manager
- Linux
- Secret Service
- Via
keyring
Bolt does not implement a credential store. Tokens are handed to the keystore your operating system already provides, which means your existing device policy governs them.
Primitives
- Signing
- Ed25519 (
ed25519-dalek) - At rest
- AES-256-GCM
- Password KDF
- Argon2
- Transport
- TLS via
rustls - Hashing
- SHA-256
Standard, widely reviewed implementations. Versions move, so we name the libraries rather than pin numbers on a page that would go stale the week we patch.
Keys are separated by purpose
At-rest keys are derived per purpose under versioned tags, so the key protecting cached content is not the key protecting an access token. Each derivation runs through one chokepoint that also refuses to seal durable data under a key that would not survive a restart.
Updates are verified before they install
Every update carries a signature that is checked against a key built into the application before anything is applied, on every platform. macOS builds are additionally Developer ID signed and notarised by Apple, and Windows builds are Authenticode signed.
These are interfaces, not hard-wiring. The audit chain already signs through your KMS (Vault, AWS KMS or PKCS#11) rather than ours, and the same shape is what lets a regulated deployment substitute its own provider elsewhere. What does not change is where inspection happens: your content is inspected on your machine, and it is never sent to Sparcle. What reaches your AI provider crosses one boundary, masked, and you choose the provider.
What ships today vs in pilot
Honest framing on shipped vs in-flight.
The same posture the trust center uses, repeated here so you can scope a pilot against shipped functionality and know what activates with your design-partner engagement.
Shipped today
- 103 in-house source connectors + Airbyte bridge (~350 sources) plus any MCP-compliant server
- 8-axis ACL pre-filter at index time (provable in the audit chain)
- Authority Policy SDK + 3 reference impls (Default · Regulated · Healthcare)
- Sealed Merkle audit chain + standalone verifier binary
- 3 deployment topologies: laptop sidecar · docker-compose · Helm
- 4 KMS variants: Vault · AWS KMS · PKCS#11 HSM · local-dev
- Cross-product audit byte-compat between Bolt and Aeira
Ships during pilot
- End-to-end ingest saga (1–2 days from green-light)
- Real-time webhook receivers for top-10 sources
- L2 Redis permission cache + webhook invalidation
- OpenFGA wire-up for tuple-mode ACL
- Late-bind on next 14 connectors (per design-partner priority)
- First published latency benchmark (target p95 ≤ 200ms on 100M-doc tenant)
Deployment
One operating model. Yours.
Bolt and Aeira self-host the data plane and the hosting in your own perimeter, always. Sparcle never hosts your data and never runs your inference. You bring the LLM, so there is no Sparcle hop to audit and no retention policy of ours to take on faith.
Intellectual Property
Patent-pending architecture, verifiable today.
Bolt's patent-pending architecture covers the runtime architecture, the priority engine, and the overlay UI. Detailed claim descriptions, novelty analysis, and implementation specifics are shared during architecture reviews under NDA.
Ready to look at the details?
Architecture briefs, security posture documentation, deployment guides, and patent claim summaries are shared during pilot evaluation under NDA. Schedule a 30-minute call and we'll cover what's relevant to your environment.