The Zero-Trust Architecture Behind bRRAIn: 8 Zones, Zero Implicit Trust

Why Zero-Trust for AI Memory?

When an AI system stores and retrieves your organization's institutional knowledge, trust boundaries matter. A single breach could expose years of client data, engagement history, and strategic decisions.

bRRAIn's architecture assumes no component, user, or session is trustworthy by default. Every request is authenticated, authorized, and audited — regardless of where it originates.

The 8-Zone Model

bRRAIn separates concerns into 8 independent zones, each with its own security boundary:

Zone 1: Authentication Gateway

All identity verification happens here. Email/password, TOTP 2FA, SAML SSO, and API key validation. The Authentication zone issues cryptographically signed session tokens that other zones validate independently.

Security properties:

• Argon2id password hashing (memory=64MB, iterations=3)
• Account lockout after 5 failed attempts (15-minute exponential backoff)
• Rate limiting: 10 login attempts per minute per IP

Zone 2: Vault

The encrypted storage layer. Every piece of data is encrypted with AES-256-GCM before it touches disk. Per-vault encryption keys are managed through envelope encryption — the master key never leaves the key management service.

// Vault encryption flow
plaintext := []byte("client engagement data")
vaultKey := kms.DeriveKey(vaultID)
ciphertext := aes256gcm.Seal(vaultKey, plaintext)
// vaultKey is never stored alongside ciphertext

Zone 3: Workspace

Logical isolation for teams and projects. Workspaces enforce data boundaries — an AI session in Workspace A cannot access data in Workspace B, even if they share the same underlying database.

Zone 4: Compute

The AI execution environment. Compute instances are ephemeral — they receive encrypted context, process it in memory, and return results. No persistent state. When a compute session ends, all in-memory data is zeroed.

Zone 5: Integration

The only zone that communicates with external systems. All third-party API calls (Salesforce, Slack, etc.) route through the Integration zone, which enforces rate limiting, credential management, and data sanitization.

Zone 6: Cache

Redis-backed caching for session state, rate limiting, and frequently accessed metadata. Cache data is encrypted and auto-expires (24-hour max TTL). The cache layer never stores raw user data — only derived or aggregate values.

Zone 7: Governance

Policy enforcement at the organizational level. Governance rules define data retention periods, classification levels, regulatory mappings, and automated compliance checks. Policies are immutable once activated.

Zone 8: Monitor

The observability layer. Prometheus metrics, structured JSON logging, and real-time alerting. Monitor zone has read-only access to other zones' metrics — it cannot modify operational data.

Encryption Stack

| Layer | Algorithm | Key Size | Rotation | |-------|-----------|----------|----------| | Data at rest | AES-256-GCM | 256-bit | 90 days | | Data in transit | TLS 1.3 | 256-bit | Auto (ACME) | | Session tokens | HMAC-SHA256 | 256-bit | Per session | | API keys | SHA-256 hash | 256-bit | On rotation | | Backup encryption | AES-256-CBC | 256-bit | Per backup |

What This Means for Your Data

1. No implicit trust. Every component authenticates to every other component.
2. Blast radius containment. A breach in one zone cannot propagate to others.
3. Complete auditability. Every data access is logged immutably.
4. Encryption everywhere. Data is encrypted at rest, in transit, and in memory (compute zone).

Learn More

• Full architecture documentation — interactive zone diagram
• Security & compliance overview — certifications and policies
• Self-hosting guide — deploy on your infrastructure