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 and Aeira system overview The customer perimeter contains the Identity stack, the Bolt agent runtime, the Aeira data plane, and the MCP-connected tool surface. Endpoint-security posture conditioning (forthcoming) joins the perimeter without breaking it: the device's posture is pulled from the existing EDR console and matched server-side. The LLM endpoint sits outside the perimeter and can be configured per the three deployment modes. CUSTOMER PERIMETER IDENTITY Your IdP SAML / OIDC / JWT identity BOLT Agent runtime orchestration · prompt assembly PII masking · audit chain multi-layer security pipeline scoped retrieval AEIRA Data plane ACL pre-filter · identity-bound keyword + vector + graph index audit-trail receipts device posture ENDPOINT POSTURE · FORTHCOMING Falcon ZTA · Defender compliance · Cortex risk pulled from your EDR console · matched server-side MCP-CONNECTED TOOLS & SOURCES · INSIDE YOUR PERIMETER M365 · Google Workspace · Slack · Jira · Salesforce · Confluence · SharePoint · GitHub · Snowflake · 103 in-house connectors outbound HTTP · PII-masked · OpenAI-compatible LLM ENDPOINT Mode A / B / C · you choose

Bolt: Enterprise Agent Platform

An agent runtime built for durability and trust.

Inside your perimeter

Self-hosted on AWS, Azure, GCP, on-prem, or fully air-gapped. Identity flows through your existing IdP (SAML, OIDC, JWT). Your data, prompts, and responses stay inside your network. When you point Bolt at a local or self-hosted model there is no outbound LLM traffic at all; when you point it at a cloud provider you chose, only the PII-masked prompt leaves, never the raw one, and never to Sparcle.

Three ways in, one policy

Your people reach AI through the Bolt desktop app, through an OpenAI-compatible endpoint on your own server that any SDK or IDE assistant can use as its base URL, or through a local relay for agent CLIs that will not accept a custom endpoint. All three resolve the same masking rules, the same model permissions, and the same audit trail, because all three ask the same server. An OS network filter observes what is left, so traffic that skips every path is visible rather than silent.

No API keys in anyone's hands

On the endpoint path people authenticate through your IdP and receive a token. The provider credentials stay server-side under a per-organisation key. Nobody holds a provider API key, so there is none to leak or share, and revoking someone in your IdP revokes their AI access with it. Each person's model list is scoped to their role, and a model outside it is refused by name rather than quietly swapped for another.

Multi-layer security pipeline

Every prompt and response passes through a multi-layer pipeline covering identity validation, PII detection, policy guardrails, rate limiting, caching, audit logging, secrets management, and privacy-preserving context handling. The pipeline is patent-pending; specific layer implementations are reviewed under NDA.

Bring your own models

Your LLM (OpenAI, Anthropic, Bedrock, Vertex, Ollama, NVIDIA NIM, or your own fine-tune), and your own embedding and reranking models too, all hot-swappable by config, and local in air-gap. With your own keys (BYOK) there's zero token markup. And keyword search plus the ACL pre-filter run with no model at all, so the base deploys CPU-only and fully offline; you add the semantic and LLM lanes only where you want them.

Durable agent lifecycle

Long-running agents survive process restarts, suspend on webhooks or timers, resume cleanly when results arrive. Sub-agent isolation, cancel cascades, heartbeat-leased multi-pod orchestration. Built for the work that doesn't finish in 5 seconds.
Bolt multi-layer security pipeline Every prompt and response passes through eight ordered layers before the LLM call dispatches: identity validation, PII detection, policy guardrails, rate limiting, cache, audit logging, secrets management, and privacy-preserving context assembly. The pipeline is patent-pending; specific layer implementations are reviewed under NDA. INBOUND PROMPT 01 Identity validation caller identity verified against IdP · session, scope, role 02 PII detection private values scanned · tokenized before the LLM boundary 03 Policy guardrails org-defined rules · model-tier floor · refusal hooks 04 Rate limiting per-tenant, per-user budgets · abuse and runaway protection 05 Cache semantic + exact-key tiers · LLM-cost reduction 06 Audit logging event metadata sealed in the BoltAuditSink Merkle chain 07 Secrets management customer-held credentials, KMS-wrapped at rest 08 Privacy-preserving context scoped assembly · only entitled, masked fragments dispatched

Aeira: Compliance-Grade Data Plane

The data plane your auditor signs off on.

Identity-bound access

Every query is automatically filtered to what the calling user is entitled to see (region, department, sensitivity clearance, role), derived from your existing IdP. Your AI agents and your auditors see the same answer. No bypass mode for callers.

Provable erasure

When a tenant invokes the Right to be Forgotten under GDPR, or you need HIPAA-aligned erasure of restricted records, Aeira gives you cryptographic proof, not just a deleted row. Auditor-acceptable, independently verifiable. The specific KMS posture and key-management semantics are shared under NDA.

Audit-trail responses

Every result carries the why-filtered context regulators ask for during reviews. What was shown, what was suppressed, why. The artifact a compliance team can actually point to when asked "how did you ensure this AI system honored access controls?"

Air-gap-ready by default

Deploy in your VPC, on-prem, or fully air-gapped. All indexing, search, and retrieval run inside your security perimeter: no outbound calls, no telemetry, no third-party model API calls. Federated tier supports multi-region with offline-validated licensing for environments with no inbound or outbound connectivity.

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

Universal signals every install benefits from: freshness, authority tier, approval lifecycle, audience targeting. Sensible defaults for any organization, regardless of vertical. Customers tune weights or swap in a vertical pack as needs evolve.

Regulated pack

Regulated-industry baseline: tighter freshness cadence, hard penalty on deprecated and archived records, emphasis on authority-tier sourcing. Compliance teams cite the right document, not the most recent draft of the wrong one.

Healthcare pack

Clinical-evidence ladder layered on the Regulated pack: clinical guidelines outrank clinical notes, expired-CME demotion, configurable per-customer evidence taxonomies. A starting point for customer-specific clinical ontology work.

Customer-written

Vertical packs and customer-specific impls slot into the same trait surface. Defense, finance, legal, federal-civilian engagements ship custom packs on the same SDK. Code lives in your repos, runs inside your perimeter, signed and reviewed by your team.
Authority Policy SDK: L4.5 placement The retrieval pipeline as a vertical stack. Source systems feed Aeira indices. The ACL pre-filter drops rows the caller cannot see. Retrieval produces a candidate set. The Authority Policy SDK sits at L4.5, between retrieval and the final rank merge. This is the customer-extensible layer. RRF rank merge then produces the final ordering, and the result plus its receipt are returned to the agent or LLM. L1 Source systems DMS · CRM · M365 · Slack · Jira · Drive · 103 in-house connectors (plus ~350 via Airbyte) L2 Aeira indices keyword + vector + graph · sharded inside your perimeter L3 ACL pre-filter identity-bound · drops rows the caller is not entitled to see L4 Retrieval candidate set · only entitled rows enter the ranker L4.5 Authority Policy SDK customer-extensible ranking · freshness, approval, evidence ladder three reference packs ship in the box · write your own in Rust or YAML ★ EXTEND HERE L5 RRF rank merge reciprocal rank fusion · keyword + vector + Authority Policy L6 Result + receipt to agent / LLM

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.

Download poster PDF Open in new tab ↗

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.

Self-Hosted
Data plane
Your perimeter
AI inference
Your LLM (BYOK / BYO)
Hosting
You
Air-gap option

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.