Data encryption — bRRAIn Docs

How bRRAIn encrypts your data at rest and in transit, and how key management works.

Data encryption

Every byte of your data is encrypted at rest and every connection is encrypted in transit. This page describes how we do it.

At rest

Envelope encryption

Vault records and files use envelope encryption:

  • Each record (or file) is encrypted with a freshly-generated Data Encryption Key (DEK) using AES-256-GCM.
  • The DEK is itself encrypted with the organization's Key Encryption Key (KEK).
  • The KEK is derived from your organization's authentication chain — its master secret, plus salts and contextual binding.
  • The encrypted DEK is stored alongside the encrypted record. The KEK never leaves protected memory.

To read a record:

  1. Authentication establishes the session has KEK access.
  2. The encrypted DEK is unwrapped using the KEK.
  3. The DEK decrypts the record.
  4. The DEK is discarded after use.

Each record gets its own DEK, so a compromise of one DEK doesn't compromise others.

Master key rotation

Your organization can rotate the master key at any time from Console → Settings → Danger zone → Rotate master encryption key. Rotation:

  1. Generates a fresh master.
  2. Derives a fresh KEK chain.
  3. Re-wraps every encrypted DEK under the new KEK.
  4. Discards the old master.

Rotation pauses Vault reads briefly (seconds) but doesn't affect availability of installed extensions or the Console. Members are not affected.

We recommend rotation annually or in response to suspected exposure.

Backups

Backups are encrypted with their own backup-specific KEK chain. Backup KEKs are not the same as primary-storage KEKs, so backup access is independently controlled.

Backup retention is configurable per Settings → Retention, with plan-tier minimums.

Files

Files (Document Portal uploads, Exchange-purchased datasets, and similar) get the same envelope encryption as records. Each file has its own DEK; large files are chunked and each chunk encrypted independently.

Database

The metadata database (organization records, member lists, audit log, billing) is encrypted at rest using full-disk encryption on the underlying storage. Sensitive fields (auth tokens, OAuth credentials, integration secrets) are additionally column-encrypted with a separate key chain.

In transit

External

Every connection to bRRAIn from a client (browser, API caller, SDK) uses TLS 1.3 by default, TLS 1.2 only as a fallback for older clients.

  • ECDHE for key exchange.
  • AEAD ciphers (AES-GCM, ChaCha20-Poly1305).
  • HSTS enforced (max-age=31536000; includeSubDomains; preload).
  • TLS certificates issued by recognized public CAs.

Inter-service

Connections between bRRAIn services (within our infrastructure) use mutually-authenticated TLS — both sides present client certificates issued by our internal CA.

Inter-pod

Connections between brain pods (e.g., for cross-region replication) use mutually-authenticated TLS over private networking.

Key management

Key chain

Each organization has a key chain:

Organization master → Organization KEK → per-record DEK → ciphertext

The master is established at organization creation. The KEK is derived using a key-derivation function with per-organization salt and contextual binding.

Where keys live

  • Master keys are held in protected memory, backed by hardware security where available.
  • KEKs are derived per-request, not cached at rest.
  • DEKs exist only in memory during read or write.
  • Encrypted DEKs are stored alongside ciphertext.

bRRAIn engineer access

bRRAIn engineers do not have routine access to your KEK. The break-glass workflow (see Zero-trust model) is the only path that grants temporary access, requires customer authorization, and is fully logged.

Bring your own key (BYOK)

On Enterprise and Sovereign-Cloud tiers, you can bring your own key:

  • Use your KMS (AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault) as the master.
  • bRRAIn calls your KMS for unwrap operations.
  • You can revoke at any time, locking us out of your data instantly.

BYOK is a strong defense against bRRAIn-side compromise: even if our infrastructure is breached, your data is not decryptable without your KMS.

Hardware-attested keys

For Sovereign-Cloud customers, master keys can live in hardware-attested HSMs:

  • FIPS 140-3 Level 3 modules.
  • Customer-controlled.
  • Cryptographic attestation that the key never leaves the module.

Key compromise response

If a customer-controlled key is compromised:

  • The customer rotates the master immediately.
  • All in-flight operations using the compromised KEK fail; clients see clear error messages.
  • An audit event records the rotation.
  • Old encrypted DEKs are no longer unwrappable; the customer must re-encrypt or restore from backup.

If we detect a compromise of bRRAIn-side keys, we notify affected customers, force-rotate, and provide an incident report with corrective actions.

Algorithms

  • Symmetric encryption — AES-256-GCM (records, files, sensitive columns).
  • Key wrapping — AES-256-KW or AEAD-based depending on context.
  • Key derivation — HKDF-SHA-256 for context binding; Argon2id for password-derived keys.
  • Asymmetric — Ed25519 for signatures, X25519 for key exchange.
  • Hashing — SHA-256 for general use; BLAKE3 for performance-sensitive paths.

We track NIST guidance and rotate algorithms as guidance evolves.

Where to next