Security Architecture: Device-Controlled Encryption & AI Data Protection

1. Cryptographic Primitives

Purpose	Algorithm	Notes
Device key agreement	X25519	Elliptic-curve Diffie-Hellman. Keypair generated on device (secure enclave / IndexedDB). Private key never transmitted.
Key wrapping	XSalsa20-Poly1305 (NaCl box)	Authenticated encryption for wrapping Master KEK per enrolled device. Immune to padding oracle attacks.
Data encryption at rest	AES-256-GCM	BadgerDB native encryption support. Hardware-accelerated on AES-NI processors.
Recovery key derivation	Argon2id	Memory-hard KDF for password-based recovery code encryption. Resists GPU/ASIC brute-force.

2. Key Hierarchy

Key	Algorithm	Generated	Stored
Device Key	X25519 keypair	On device at enrollment	Private: device secure enclave / IndexedDB. Public: server (device registry)
Master KEK	256-bit random	At account creation	Server-side, one wrapped copy per enrolled device
User DEK	AES-256-GCM	At account creation	Server-side, wrapped by Master KEK
Project DEK	AES-256-GCM	At project creation	Server-side, wrapped by Master KEK
Recovery Key	Argon2id-derived	At account creation	Printed QR code (offline only)
Org Recovery Key	X25519 keypair	At org creation (enterprise)	HSM or admin-managed

3. Session Lifecycle

1. Authentication: user authenticates via WebSocket. Device sends its public key.
2. Key unwrap: server retrieves the Master KEK blob wrapped for this device. Device unwraps using its private key, sends plaintext DEKs back over TLS-encrypted WebSocket.
3. Session active: DEKs held in a session keyring (in-memory map, per-connection). Hard expiry ceiling of ~4 hours. Each browser tab gets an independent keyring entry.
4. Session end: on disconnect, tab close, or expiry — keyring entry is zeroed from memory. Data on disk returns to opaque ciphertext.
5. Server restart: all keyring entries lost. Users must re-authenticate and re-unwrap keys.

4. Threat Model

Protected scenarios

• Data at rest: stolen or seized server disks contain only AES-256-GCM ciphertext. Unreadable without the user’s device or recovery key.
• Compromised backups: database backups are encrypted. No plaintext DEKs exist in persistent storage.
• Insider access: server operators cannot read user data outside of an active session. No master decryption key exists.
• Cross-user isolation: per-user databases with per-user DEKs. Compromising one user’s key reveals nothing about other users.

Accepted risk

• Memory-level attack during active session: an attacker with access to server memory during an active session could extract DEKs for currently-connected users. This is inherent to any system where the server processes user data for AI agents. Mitigated by session expiry ceiling (~4 hours), memory zeroing on disconnect, and hardware isolation in enterprise deployments.

5. Device Enrollment and Revocation

First device (account creation)

1. Device generates X25519 keypair and random 256-bit Master KEK locally.
2. Device wraps Master KEK using NaCl box (device private key + server ephemeral key).
3. Device generates User DEK, wraps it with Master KEK.
4. Wrapped Master KEK blob, device public key, and wrapped User DEK are sent to the server.
5. Server stores wrapped blobs and public key in the device registry.

Subsequent devices

1. New device generates its own X25519 keypair.
2. Existing device (trust anchor) unwraps Master KEK, re-wraps it for the new device’s public key.
3. New wrapped blob stored server-side.

Device revocation

1. Revoked device’s session is killed immediately via broadcast.
2. New Master KEK is generated. All DEKs (User DEK + all Project DEKs) are re-wrapped with the new Master KEK.
3. New Master KEK is wrapped for each remaining enrolled device.
4. Revoked device’s wrapped blob is deleted. Its old copy of the Master KEK is now useless (different key).

6. Recovery Tiers

Tier	Mechanism	Availability
Multi-anchor	2+ enrolled devices. Lose one, the other restores access.	All users
Printed recovery code	QR code containing Master KEK encrypted with Argon2id(user-chosen password, random salt). Printed and stored offline.	All users
Organization escrow	Master KEK additionally wrapped to an organization recovery key stored in an HSM.	Enterprise only
Total loss	All anchors + recovery code + escrow lost. Data is irrecoverable by design.	N/A

7. AI Data Protection Pipeline

Layer	Component	Function
1. Classification	Data Classification Engine	Classifies content by sensitivity tier (public, internal, confidential, restricted). Detects credentials, PII, proprietary patterns, and custom org-defined rules.
2. Inbound filter	Inbound Threat Filter	Computes a composite risk score for each query. High-risk content is blocked or flagged. Prevents sensitive data from reaching external AI models.
3. Model trust	Model Configuration Registry	Each AI model is assigned a trust tier (local, internal, cloud, external). Queries are routed only to models whose trust tier meets or exceeds the content’s sensitivity clearance.
4. Outbound guard	Outbound Data Guard	Scans AI-generated responses for data leakage — credentials, PII, or patterns that shouldn’t appear in output. Blocks or redacts before delivery.
5. Redaction	Report Redaction Engine	Applies viewer-clearance-based redaction to reports. Content above the viewer’s clearance level is replaced with redaction markers.

8. Data Isolation Architecture

All user data is stored under an isolated directory: data/<userID>/. No user content exists in shared databases, PostgreSQL, or Redis.

Database	Contents	Encryption
settings.db	Preferences, chat sessions, project index, model config	User DEK (AES-256-GCM)
memory.db	Knowledge entities, topics, relationship edges	User DEK (AES-256-GCM)
projects/<id>/project.db	Research graph nodes, budget state, runtime data	Project DEK (AES-256-GCM)

PostgreSQL stores only identity data (email, password hash, org membership). Redis stores only ephemeral runtime state (session tokens, rate limits). Neither contains user-generated content.

GDPR deletion: rm -rf data/<userID>/ removes all user data. Because each database is encrypted with the user’s DEK, deletion is final — no residual plaintext exists anywhere in the system. See our EU legal framework guide for the regulatory context.

9. Audit Trail

Security-relevant events are logged to a tamper-evident audit trail:

• Device enrollment and revocation
• Key rotation events
• Session creation and termination
• Inbound filter blocks and outbound guard triggers
• Sensitivity classification decisions
• Model trust tier overrides

Companion documents

• The consumer-facing Security overview summarises this whitepaper for a non-technical audience.
• The Multi-Backend Architecture with Layered Post-Quantum Encryption whitepaper extends the model documented here to a horizontally-scaled deployment and the hybrid post-quantum envelope that protects against future cryptanalytic attack.