Vaults — bRRAIn Docs

Understanding bRRAIn Vaults: encrypted storage boundaries, key management, and data isolation.

Vaults

A Vault is the primary encryption and isolation boundary in bRRAIn. Every memory object, embedding, and metadata record belongs to exactly one vault. Vaults ensure that data from different tenants, departments, or classification levels is cryptographically separated, even when stored on the same physical infrastructure.

Vault Concept

When you create a bRRAIn account, a default vault is provisioned automatically. Most small teams operate with a single vault. Larger organizations create multiple vaults to enforce data boundaries aligned with their compliance requirements.

Each vault has:

  • A unique identifier (vlt_ prefix)
  • A human-readable name
  • An encryption key (platform-managed or customer-managed)
  • A data residency region
  • One or more workspaces

Memory objects stored in one vault are invisible and inaccessible to users and API keys scoped to a different vault. There is no cross-vault query mechanism by design. If you need to share knowledge between vaults, you must explicitly export and re-import it.

Encryption Model

bRRAIn uses a layered encryption approach:

Envelope Encryption

Each vault has a Data Encryption Key (DEK) that encrypts all memory objects within that vault. The DEK itself is encrypted by a Key Encryption Key (KEK) stored in a hardware security module (HSM). This envelope encryption model means that even if storage media is compromised, the data remains unreadable without access to the HSM.

Memory Object --> encrypted with DEK --> stored in Storage Zone
DEK --> encrypted with KEK --> stored in Security Zone
KEK --> managed by HSM (never leaves hardware boundary)

Encryption at Rest

All data within a vault is encrypted using AES-256-GCM. Each memory object receives a unique initialization vector (IV), preventing pattern analysis across objects. Metadata indexes are encrypted separately, with the index structure designed to support search without decrypting the underlying content.

Encryption in Transit

All communication between zones and between clients and the API uses TLS 1.3 with certificate pinning. Internal zone-to-zone traffic uses mutual TLS (mTLS) with short-lived certificates rotated every 24 hours.

Key Management

Platform-Managed Keys

By default, bRRAIn manages encryption keys on your behalf. Platform-managed keys are generated in FIPS 140-2 Level 3 certified HSMs, rotated automatically every 90 days, and backed up to geographically distributed key stores. This option requires no configuration and is suitable for most deployments.

Customer-Managed Keys (BYOK)

Enterprise customers can bring their own keys (BYOK) for maximum control. bRRAIn integrates with:

  • AWS KMS (Key Management Service)
  • Google Cloud KMS
  • Azure Key Vault
  • HashiCorp Vault (self-hosted)

When using BYOK, the KEK resides in your key management infrastructure. bRRAIn requests key operations (wrap/unwrap) through the provider's API but never has direct access to the key material. Revoking the key in your KMS immediately renders all vault data inaccessible.

Key Rotation

Key rotation replaces the DEK without re-encrypting existing data immediately. New writes use the new DEK, while reads transparently handle objects encrypted with previous keys. A background process gradually re-encrypts older objects. You can also trigger an immediate full re-encryption through the admin API if required by policy.

Creating a Vault

Create a vault using the REST API:

curl -X POST https://api.brrain.io/v1/vaults \
  -H "Authorization: Bearer brr_live_YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Engineering Vault",
    "region": "us-east-1",
    "key_management": "platform"
  }'

Vault Policies

Each vault supports configurable policies:

  • Retention policy: Automatically archive or delete memory objects after a defined period
  • Access policy: Restrict which IP ranges or identity providers can access the vault
  • Size quotas: Limit the total storage consumed by a vault
  • Audit requirements: Enforce that all access events are logged to an external SIEM

Next Steps