Trust Model and Security Architecture

1. Executive Summary

BaseLayer is a memory layer for AI workflows designed around user control, encrypted transport, and minimal data exposure. The product is built so cloud systems can relay encrypted state without needing access to plaintext memory.

The architecture follows three non-negotiable constraints: user-owned memory, local-first processing, and a zero-knowledge relay model for cloud synchronization and orchestration.

2. Core Security Principles

• Zero-knowledge cloud: cloud services process encrypted blobs rather than plaintext memory.
• Local-first operation: extraction, indexing, and retrieval logic execute on user-controlled machines.
• Strong ownership boundaries: vault access is scoped to the authenticated owner and isolated across tenants.
• Encryption at rest and in transit: local vaults encrypted with SQLCipher; relay data encrypted with AES-256-GCM.
• Privacy by default: telemetry is opt-in and disabled by default. No plaintext conversation storage in cloud relays.

3. Threat Model

4. Cryptographic Controls

4.1 Key Generation & Storage

A 256-bit master encryption key is generated locally using a cryptographically secure random number generator. This key is stored in the macOS Keychain via a dedicated keychain database (baselayer.keychain-db) using the security CLI. The master key is never written to a plain file on the filesystem.

4.2 Double-Envelope Passphrase System

To enable cross-device access without transferring key files, BaseLayer implements a double-envelope key wrapping system:

1. User provides a passphrase during onboarding.
2. PBKDF2-SHA256 with 600,000 iterations derives a wrapping key from the passphrase + random salt.
3. The wrapping key encrypts (wraps) the master key.
4. The wrapped master key and salt are stored in Firestore (cloud never sees the plaintext master key).
5. On a new device, entering the passphrase re-derives the wrapping key and unwraps the master key, which is then stored in the local OS Keychain.

4.3 Encryption in Transit

• Authenticated encryption (AES-256-GCM) is used for all relay data in transit and synchronization artifacts.
• Session keys are derived daily from the master key using HKDF-SHA256 with domain separation.
• 12-byte cryptographically random nonces per message; 16-byte GCM authentication tags for integrity.
• Tamper detection — any modification causes decryption to fail.

4.4 Encryption at Rest

The local vault database is encrypted using SQLCipher with AES-256-CBC full-database encryption (bundled-sqlcipher-vendored-openssl). This protects the vault file even if the device is physically compromised. Existing plaintext vaults are automatically migrated to encrypted format on first open.

4.5 Key & Data Storage Summary

5. Access Control and Isolation

BaseLayer enforces owner-scoped access boundaries for each vault and prevents cross-vault data access. Each user's vault is stored at a unique, isolated path (~/.baselayer/vaults/{vault_id}/vault_vfs.db). Administrative server workflows are isolated from client pathways and used only for controlled service operations.

Local service surfaces are bound to localhost interfaces to reduce network attack exposure and rely on operating system process boundaries for local trust zoning.

Sign-out preserves the encrypted vault on disk but clears all session state. Re-entry requires the user's passphrase to unwrap the master key and decrypt the vault.

6. MCP Security

Remote MCP connections (e.g., from Claude.ai) authenticate via OAuth 2.1 with PKCE, following the standard authorization code flow with proof key for code exchange to prevent authorization code interception attacks.

The MCP server publishes a heartbeat every 30 seconds. The relay performs pre-checks before forwarding any request, ensuring stale or disconnected servers are detected immediately rather than silently failing. Real-time Firestore listeners (onSnapshot) provide instant state synchronization without polling.

7. Privacy Guarantees

• Opt-in telemetry: telemetry is disabled by default. If the user opts in during onboarding, only anonymous, aggregate usage data is collected. No conversation content, personal information, or vault data is ever included.
• No plaintext conversation payloads retained in cloud relay storage.
• Memory and retrieval computation remain local to the user environment.
• Firestore documents contain only encrypted payloads, nonces, status flags, content hashes, and the passphrase-wrapped master key. No PII.

8. Security Program and Roadmap

The following security milestones are planned:

• Formal security audit (post-seed): engage a third-party security firm for comprehensive penetration testing and cryptographic review.
• Cross-platform key storage (post-macOS): Windows Credential Manager and Linux Secret Service integration for Keychain parity.
• Hardware key support (v3+): YubiKey and hardware security key support for vault authentication.
• SOC 2 Type I (post-Series A): pursue SOC 2 compliance for enterprise customers.

Public disclosures of major security posture updates will be reflected in subsequent whitepaper versions.

Appendix A: Cryptographic Primitives

Appendix B: File System Layout

Note: The master encryption key is stored exclusively in the macOS Keychain and is not present as a file on the filesystem. The wrapped (passphrase-protected) copy of the master key is stored in Firestore for cross-device access.

9. Responsible Disclosure

Researchers can report vulnerabilities to security@baselayer.id.

Include impact, reproducibility steps, and recommended remediation context where possible.