Security is not a feature. It’s the architecture.
bRRAIn was built security-first — every zone, every session, every byte of institutional memory is encrypted, audited, and governed by zero-trust principles.
Zero-trust 8-zone architecture
bRRAIn is not a monolithic application with security added after the fact. It is an 8-zone architecture where every zone enforces its own security boundary. No zone trusts another implicitly. Every request is authenticated, authorized, and inspected before it crosses a zone boundary.
Zone 0 — Auth Gateway
Identity verification, MFA enforcement, session token issuance. Every request starts here. No exceptions.
Zone 1 — API Router
Request routing, rate limiting, payload validation. Malformed or oversized requests are rejected before they reach business logic.
Zone 2 — Session Manager
Session isolation, per-session encryption keys, workspace context binding. Sessions cannot access data outside their scope.
Zone 3 — Memory Engine
Persistent context storage, semantic retrieval, cross-session threading. All data encrypted at rest with per-vault keys.
Zone 4 — Compute Sandbox
Isolated execution environment for AI inference. No direct access to the vault. All outputs pass through Zone 7 before storage.
Zone 5 — Integration Layer
Third-party connectors with credential isolation, OAuth scope enforcement, and bidirectional data sanitization.
Zone 6 — MCP Gateway
Sandboxed execution for Model Context Protocol tools. Bidirectional firewall inspects every request and response.
Zone 7 — Security Policy Engine
The dedicated security zone. Every operation passes through Zone 7 before it touches the vault. Policy enforcement, content classification, PII detection, and audit compliance live here.
Security isn’t bolted on. It’s Zone 7 — a dedicated security policy engine that inspects every operation before it touches the vault.
Zone 7 — The security policy engine
Zone 7 is the heart of bRRAIn’s security model. Every write operation passes through two inspection gates before data reaches the vault. Every read operation is checked against the requester’s role, session context, and active policies.
Gate 1: Pre-Queue Inspection
Before an operation enters the processing queue:
- Content classification — categorizes data by sensitivity level (public, internal, confidential, restricted)
- PII and credential detection — scans for SSNs, API keys, passwords, credit card numbers
- Policy violation checks — validates against workspace and organization-level policies
- Rate limiting — per-user and per-session throughput limits
- LLM provenance validation — verifies the AI model is on the approved allowlist
Gate 2: Pre-Vault-Write Inspection
After processing, before data is committed to the vault:
- Conflict detection — checks for concurrent write conflicts and data integrity violations
- Final policy checks — re-validates against policies updated during processing
- Audit compliance — ensures all required metadata is present for compliance logging
- Schema validation — verifies data conforms to the vault’s schema requirements
Progressive enforcement
Zone 7 does not operate in binary pass/fail mode. It uses progressive enforcement to handle policy violations proportionally:
At each stage, the user receives clear feedback about what triggered the enforcement action and what they can do to resolve it. Administrators receive real-time alerts for block and quarantine events.
No silent failures. Every violation is logged, escalated, and traceable.
Encryption everywhere
bRRAIn encrypts data at every stage of its lifecycle — at rest, in transit, and in session memory. There is no point in the data flow where information exists in plaintext on disk.
At rest
AES-256-GCM with per-vault envelope encryption. Each vault has its own data encryption key (DEK), encrypted by a master key (KEK). Rotating the master key does not require re-encrypting the vault.
In transit
TLS 1.3 enforced on all connections — including internal service-to-service communication. No plaintext within bRRAIn infrastructure. Certificate pinning available for self-hosted deployments.
Session keys
Per-session derived keys isolate workspace data within active sessions. When a session ends, the session key is destroyed. Compromised tokens cannot decrypt other sessions.
Key management
Hardware Security Module (HSM) support for master key storage. Automatic key rotation on configurable schedules. Bring Your Own Key (BYOK) for Enterprise customers.
Your data is encrypted before it touches disk. Session keys ensure even bRRAIn engineers can’t read your vault.
Role-based security governance
bRRAIn uses a 7-tier role hierarchy that governs who can access, modify, and administer every aspect of the platform. Security policies can only be set or modified by Tier 0 (Sovereign) and Tier 1 (Architect) roles.
| Tier | Role | Security Privileges | MFA |
|---|---|---|---|
| 0 | Sovereign | Full platform control. Set global policies, manage encryption keys, override any restriction. | Enforced |
| 1 | Architect | Define security policies, configure zone rules, manage role assignments. | Enforced |
| 2 | Librarian | Manage vault structure, content policies, and knowledge organization. | Enforced |
| 3 | Operator | Execute operations within policy boundaries. Cannot modify policies. | Optional |
| 4 | Contributor | Add content to assigned workspaces. Read access governed by workspace policies. | Optional |
| 5 | Observer | Read-only access to assigned workspaces. No write permissions. | Optional |
| 6 | Guest | Time-limited, scoped access to specific resources. Automatically expires. | Optional |
All policy changes are versioned with a complete audit trail. Any policy modification can be rolled back to a previous version by Tier 0 or Tier 1 roles.
The Security Controller (bRRAInOps) is the certified professional who actively audits sessions and dynamically adjusts security rules. Learn about the Security Controller certification →
The Operations Controller holds sovereign-tier access — the highest authority in the bRRAIn governance model. Learn more →
LLM security — controlling what AI can access
bRRAIn gives organizations granular control over which AI models can be used, by whom, and through which interface. LLM allowlisting is enforced per user, per project, and per delivery mechanism.
| Interface | Allowed Models | Restriction Level |
|---|---|---|
| CLI | claude-*, mistral-*, llama-* |
Standard |
| Browser Extension | claude-3-sonnet-*, mistral-7b-* |
Restricted |
| Mobile | claude-3-sonnet-* only |
High |
| API | Any (with provenance tracking) | Tracked |
MCP Gateway (Zone 6)
The Model Context Protocol Gateway provides a sandboxed execution environment for AI tool use. Every MCP request and response passes through a bidirectional firewall that inspects content, validates permissions, and logs the interaction.
- Sandboxed execution — MCP tools run in isolated containers with no direct vault access
- Bidirectional firewall — both requests to and responses from MCP tools are inspected
- Request/response inspection — content is classified and checked against active policies
- Tool allowlisting — only approved MCP tools can be invoked, per workspace and per role
Every AI interaction is tagged with provenance metadata — user, role, model, timestamp, audit trail link.
Cybersecurity risk registry
bRRAIn includes a built-in risk registry that tracks cybersecurity risks across the organization. Unlike static spreadsheets, the bRRAIn risk registry is deeply integrated with institutional memory — every risk is linked to the key decisions, learnings, and sessions that inform it.
What the risk registry captures
When a cybersecurity risk is identified, the system captures a comprehensive record:
- Identification — date discovered, reporting user, discovery method (manual, automated scan, incident response)
- Classification — risk category, severity (critical/high/medium/low), likelihood, potential impact
- Context — trigger conditions, affected systems, related decisions, historical precedents
- Response — mitigation strategy, contingency plan, assigned owner, review schedule
- Lineage — links to every session, decision, and policy change related to this risk
Compounding intelligence
Because bRRAIn’s memory is persistent, the risk registry compounds intelligence over time. Traditional risk registers are updated manually and reviewed periodically. bRRAIn’s risk registry inherits context from every security event, every policy change, and every audit session automatically.
When a new vulnerability is discovered, bRRAIn’s memory can instantly cross-reference it against every prior incident, every decision that led to the current architecture, and every session where similar risks were discussed.
What cybersecurity specialists can do
- Build incident response plans informed by the complete history of similar incidents
- Prioritize remediation based on risk severity, business impact, and historical resolution patterns
- Create stories and tasks that inherit full risk context — no manual re-documentation
- Trace the lineage of any risk from initial creation through mitigation and verification
- Generate compliance reports that cross-reference risks against regulatory requirements
Traditional risk registers are static spreadsheets. bRRAIn’s risk registry is alive — it inherits context from every security event, every policy change, and every audit session.
Scope creep as a security risk
Scope creep is typically discussed as a project management problem. bRRAIn treats it as a security risk. When the scope of a project, workflow, or system expands beyond its original boundaries, it can introduce security vulnerabilities — especially when features are rushed, security reviews are skipped, or compliance boundaries are crossed without assessment.
How bRRAIn tracks scope creep
- Scope creep is a formal risk category in the bRRAIn risk registry
- The system flags when project scope expands beyond defined thresholds
- Security implications are highlighted before deployment, not discovered after
- For software teams: scope changes tracked against release plans with automated security impact assessment
- For non-software industries: scope changes in workflows, processes, and operational procedures tracked with the same rigor
When the system detects that a healthcare workflow has expanded beyond its original security boundary, it flags this as a risk, links it to the relevant compliance requirements (HIPAA, SOC 2), and recommends a security review before the change is deployed.
Industry examples
Healthcare
A new patient data workflow exceeds the original HIPAA boundary. bRRAIn flags the expansion, links it to PHI handling requirements, and blocks deployment until a security review is completed.
Banking
A transaction processing change impacts PCI DSS scope. The system identifies the compliance boundary violation and escalates to the security controller for assessment before production.
Insurance
A claims workflow modification affects data residency requirements. bRRAIn detects that the new workflow routes data through a region violating the organization’s data sovereignty policy.
Scope creep tracking applies across all industries that bRRAIn serves. See industry-specific use cases →
Compliance certifications
bRRAIn is designed to meet the compliance requirements of regulated industries. Our compliance program includes independent audits, continuous monitoring, and documented controls.
SOC 2 Type II
Independent third-party audit of security controls, availability, processing integrity, confidentiality, and privacy. Audit engagement in progress with target completion in 2026.
HIPAA
Business Associate Agreements (BAA) available. Full support for Protected Health Information (PHI) handling with encryption, access controls, and audit requirements.
GDPR
Data residency controls, right-to-erasure support, Data Processing Agreements (DPA) available, and EU hosting options. Data portability supported.
FedRAMP
Government deployment readiness on the product roadmap. Architecture designed to meet FedRAMP Moderate baseline requirements.
Annual third-party penetration testing by independent security firms. Results available under NDA for Enterprise customers. Responsible disclosure program for security researchers.
Data residency
bRRAIn provides full control over where your data is stored and processed. Choose the region that meets your regulatory requirements, or self-host for complete sovereignty.
United States
Data stored and processed in US-based data centers. SOC 2 and HIPAA compliant infrastructure.
European Union
Data stored and processed within the EU. GDPR-compliant with data residency guarantees.
Asia-Pacific
Data stored and processed in APAC region. Supports regional data sovereignty requirements.
Self-hosted deployments provide full data sovereignty — your data never leaves your infrastructure. Air-gapped deployment options available for classified environments.
No data leaves your chosen region. Processing and storage are co-located within the same jurisdiction.
Audit trail
bRRAIn maintains immutable, append-only audit logs for every operation. Logs are cryptographically signed to prevent tampering and stored separately from application data.
Every operation is tagged
Retention
Default retention: 90 days. Configurable up to 7 years for organizations with long-term compliance requirements. Logs can be exported to external SIEM systems in real-time via streaming integration.
Incident reconstruction
Complete lineage in seconds, not weeks. Audit logs integrate with major SIEM platforms: Splunk, Datadog, Elastic, and custom webhooks for real-time streaming to your security operations center.
CC/DE governance model
bRRAIn uses a Centralized Command / Decentralized Execution (CC/DE) governance model for security operations. This model ensures consistent policy enforcement while empowering field operators to work efficiently within defined boundaries.
Centralized Command
The Security Controller and Operations Controller define global policies, set enforcement thresholds, and manage the organization’s security posture from a single command point.
Decentralized Execution
Field operators enforce policies within defined thresholds. They have the autonomy to act on operational decisions without waiting for central approval — as long as they stay within policy boundaries.
Management by Exception
Only violations trigger human review. Normal operations flow without friction. When a threshold is breached, the system escalates to the appropriate controller for review.
Trust but Verify
Operators are empowered to make decisions. Audit logs verify compliance after the fact. This creates a culture of accountability without bottlenecks.
OODA Loop cadence
- Daily Async security reports delivered to controllers with anomaly highlights
- Weekly Audit reviews covering policy violations, enforcement actions, and risk registry updates
- Monthly Risk assessments with cross-referenced institutional memory for trend analysis
Learn about the Security Controller certification → | Operations Controller → | Access Controller →
See security in action
Request a demo to see how bRRAIn’s zero-trust architecture, risk registry, and progressive enforcement work in practice.