Security is not a feature. It’s the architecture.
bRRAIn was built security-first — every request is authenticated, authorized and logged, every zone enforces its own boundary, and every change to institutional memory lands in a hash-chained audit log.
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.
Z1 — Vault
The canonical store of your organization’s knowledge. Written only through governed paths, read only within the requester’s role and project permissions.
Z2 — Workspaces
Per-user and per-project working areas where sessions and drafts live. A session cannot reach data outside its scope.
Z3 — Control Plane
Identity, roles, permissions, policy decisions and organization configuration. SSO, per-project permissions and custom roles are decided here.
Z4 — Conflict Zone
Detects and resolves conflicting writes and contradictory knowledge before they reach the canonical vault.
Z5 — Notifier
Event fan-out: notifications, digests and webhooks, so security events reach the people and systems that need them.
Z6 — MCP Gateway
The governed entry point for AI tools and agents using the Model Context Protocol. Every tool call is authenticated, permission-checked and logged.
Z7 — Security Policy Engine
The dedicated security zone. Evaluates security and data-handling policy on every request and produces audit evidence.
Z8 — Code Sandbox
Isolated execution for code and extensions, kept apart from the vault and the control plane.
Security isn’t bolted on. It’s Z7 — a dedicated security policy engine that evaluates every request 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 protects data in transit, in active sessions and in snapshots, and lets you choose the hosting model whose key custody and storage controls fit your requirements.
At rest
Session workspaces and disaster-recovery snapshots are encrypted with AES-256-GCM. Storage-level encryption and key custody depend on the hosting option you choose — ask us for the details of yours.
In transit
All connections to bRRAIn surfaces — Nexus, console, mobile and MCP clients — use TLS. Automation authenticates with personal access tokens rather than shared passwords.
Session keys
Per-session keys isolate workspace data within active sessions, so one session’s data is not readable from another.
Key management
On Sovereign On-Prem deployments you hold the infrastructure and its keys. On hosted options, key custody is documented as part of your hosting quote.
Choose where your vault runs and who holds the keys — up to a deployment on your own infrastructure.
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. By default bRRAIn uses the Handler, its own language model served locally on your bRRAIn instance. Commercial models are opt-in, added per organization through the LLM Registry.
| Interface | Allowed Models | Restriction Level |
|---|---|---|
| Default | The Handler (bRRAIn’s own model, served locally) | On by default |
| Commercial models | Claude, GPT, Gemini and others — only once your organization adds them | Opt-in |
| AI tools and agents | Through the MCP Gateway under the caller’s role and permissions | Governed |
| All model use | Recorded in the audit log | Tracked |
MCP Gateway (Z6)
The Model Context Protocol Gateway is the governed entry point for AI assistants and agents. Every MCP request is authenticated, checked against the caller’s permissions and logged.
- Role-scoped access — an assistant sees only what the signed-in user’s role and project permissions allow
- Permission-gated invocation — invoking MCP tools is itself a permission that roles grant or withhold
- Policy evaluation — requests are evaluated by the Security Policy Engine (Z7)
- Isolated code — code and extensions run in the Code Sandbox (Z8), apart from the vault
Every AI interaction is attributable — who asked, under which role, through which model, and when.
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 support
bRRAIn gives you the controls and the evidence trail regulated work depends on. Robo Compliance helps you map your own controls and evidence to frameworks such as SOC 2, HIPAA, PCI DSS, CMMC 2.0 Level 2 and the NIST AI RMF, run control tests, and hand external auditors sealed, signed audit sessions through a scoped, expiring auditor portal. Your certification or attestation is issued by your auditor; bRRAIn helps you prepare and evidence it.
SOC 2
Map access control, change management and logging controls to the evidence bRRAIn already produces: role and permission records, the hash-chained audit log, and sealed audit sessions for your auditor.
HIPAA
Scope who can reach which projects with per-project permissions, keep a tamper-evident record of access, and run on the hosting option your PHI policy requires — including Sovereign On-Prem.
GDPR
Role-based access, deletion and export tools that support data-subject requests, and hosting options — Hosted Standard, Co-located, Data-Resident and Sovereign On-Prem — chosen to fit your residency obligations.
PCI DSS · CMMC 2.0 L2 · NIST AI RMF
The same Robo Compliance workflow: framework catalog, control tests, evidence, findings with a lifecycle, and sealed sessions an external assessor can verify.
Found a vulnerability? Report it through our security contact — we welcome responsible disclosure.
Data residency
You choose where bRRAIn runs. Hosting is quoted to your configuration, so the location, facility and controls are written into your agreement rather than assumed.
Hosted Standard & Co-located
bRRAIn runs your dedicated instance for you, in a shared or co-located facility agreed in your quote.
Data-Resident
Your instance is hosted in the country or region named in your agreement, to support local residency obligations.
Sovereign On-Prem
bRRAIn runs on infrastructure you own and operate, under your own physical and network controls, including isolated networks.
Where your data is stored and processed depends on the option you choose and on the AI models you enable: the default Handler model runs on your instance, while any commercial model you opt into is a provider your organization has chosen to send prompts to.
Residency is a contract term, not a slogan. Your agreement states where your instance runs.
Audit trail
bRRAIn keeps an append-only, hash-chained audit log: each record carries the hash of the one before it, so any edit or deletion breaks the chain and shows. Signed audit logs can be verified independently.
Every operation is tagged
Retention
Audit records are readable and exportable by the roles you grant audit permissions to, so you can keep them as long as your obligations require and feed them into your own security tooling.
Incident reconstruction
Trace an incident from session to operations, policy checks, decisions and risk context. Export audit records, or use webhooks to send security events 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.