Security

Responsible language. Documented hazards.

We do not describe Quesar as 100% private, completely secure, military-grade, or unhackable. Security claims track source, tests, and operator choices.

Security whitepaper

Controls, as implemented.

Last updated September 22, 2026. Each control is labeled with its status; nothing below is a certification claim.

  1. 1.Deployment boundary

    Current

    The static preview has no server functions, authentication, or database. The source also supports a configured server deployment. DATABASE_URL selects durable Postgres; without it, in-memory PGLite does not survive a process restart. Rate-limit counters use the database.

  2. 2.Identity, provider, and sealing controls

    Current

    Protected console functions use Better Auth sessions. Supported sign-in methods are offered according to configuration. Admin access requires an allowlisted email plus a linked Google or Apple account. Conversation audits and workspace refresh tokens use AES-256-GCM under APP_ENCRYPTION_KEY with owner and purpose binding; inquiry fields are not covered by that application-level sealing.

  3. 3.Conversation audits and admin review

    Current

    Website model requests from Console Chat, the persona chat, the configured desk, and workspace Ask Abbey require current audit consent and audit encryption. Each successful exchange is sealed and stored before its reply returns. Audits have a 365-day expiry; automatic deletion requires the configured expiry endpoint and scheduler. Owners can list, read, export, and delete their audits. Admin audit review requires the admin decision and a stated reason, with access events recorded.

  4. 4.Responsible disclosure

    Current

    If you discover a vulnerability in Quesar infrastructure, demos, or integration materials, contact cbkshadow@icloud.com with reproduction details and impact notes.

What we will say

  • Ed25519 signatures and SHA-256 content addressing are used on WDBX transaction and segment objects where implemented.
  • ABI workers describe authenticated, audience-bound admission with finite leases and replay resistance as contracts — not as a deployed cluster.
  • Abbey daemon authentication uses a local bearer token on a Unix socket when that surface is run.
  • GPU capability reporting is honest about missing kernels rather than implying acceleration that is not linked.

What we will not say

  • That the reference cluster protocol is production sharding.
  • That FHE reference paths, AES/RBAC, or key rotation are complete products.
  • That the local site builder is safe to expose beyond a trusted LAN.
  • That storing a record makes it true, or that a signature makes a deployment federated.