Zero-trust model — bRRAIn Docs

How bRRAIn implements zero trust — assume breach, verify always, scope minimally.

Zero-trust model

Zero trust is the security posture bRRAIn takes by default everywhere. This page describes what that means in practice for your data, your members, and your integrations.

The three principles

Zero trust as we apply it:

  1. Assume breach. Design every system as if an attacker is already inside the network. No internal trust by default.
  2. Verify always. Every action is checked against current credentials and policy at the moment of action. No standing trust.
  3. Scope minimally. Every credential carries the smallest possible scope to do its job. No "admin" tokens with the keys to everything.

These three principles drive every design choice in bRRAIn.

How we apply zero trust

Authentication

  • Every API call carries a bearer token, session cookie, or service-account credential. Anonymous access is the rare exception (public listings, healthchecks).
  • Credentials carry an issuer, an issue time, an expiry, and an audience claim. Mismatched claims are rejected.
  • MFA is enforceable per organization. Enterprise can require MFA on every action, not just sign-in.
  • SSO and SCIM let your IdP be the source of truth for identity.

Authorization

  • Every action is checked against the actor's role and the resource's scope at request time. No cached "yes, you're an admin" memory.
  • Roles compose with scopes (zone, project, time, action). The smallest permission that satisfies the action is checked.
  • Policy violations return clear, actionable errors without leaking information about what's behind the policy.

Network

  • Every connection between bRRAIn services is mutually-authenticated TLS.
  • Every external connection to or from bRRAIn is TLS 1.3.
  • Inter-zone communication inside a brain pod uses isolated namespaces.
  • The MCP Gateway is the only path out of the pod for non-system traffic.

Storage

  • Vault data is encrypted with envelope encryption — per-record DEK wrapped by per-org KEK derived from the organization's authentication chain.
  • Even bRRAIn engineers cannot decrypt customer data without break-glass workflow.
  • Backups are encrypted with the same model and stored separately from primary storage.

Compute

  • Compute zones isolate workloads (see Compute zones).
  • Each marketplace extension runs in its own zone with declared scopes.
  • Sandboxed code runs in the locked-down sandbox zone.

Audit

  • Every action is logged with actor, verb, resource, scope, and outcome.
  • Audit logs are append-only and cryptographically tamper-evident.
  • Logs are available to your security team in real time.

Break-glass workflow

A few operations cannot be done without bRRAIn engineering involvement (e.g., recovery from a state where every Sovereign account has lost MFA). For these:

  • Break-glass requires written customer authorization.
  • Two-person operator authorization on the bRRAIn side.
  • All actions logged and surfaced in your audit trail.
  • Post-action review report.

We design to minimize the actions that need break-glass; we make it clear when break-glass is the only path; we make it auditable when used.

What zero trust doesn't mean

Zero trust isn't paranoia. It's calibrated skepticism:

  • We trust your members to do their job — within the scope you've given them.
  • We trust integrations to work — within the rate and policy you've configured.
  • We trust extensions to function — within the zone and scopes they declared at install.

Zero trust says: when something departs from those expectations, our systems notice and your audit log records it.

Threat model

Top-of-list threats we design against:

  • Credential theft — defended by MFA enforcement, short-lived tokens, anomaly detection.
  • Lateral movement — defended by zone isolation, scope minimality, no implicit trust between extensions.
  • Insider threat — defended by audit logging, role-scope minimality, approval gates on sensitive actions.
  • Supply chain — defended by signed binaries, signed configurations, no public package registries in the deployment path. See Source & deployment policy.
  • Data exfiltration — defended by MCP Gateway egress controls, integration policies, rate limits, audit logging.
  • Service disruption — defended by quotas, rate limits, isolation, observability.

What we don't claim

  • We don't claim absolute security. No system can promise that.
  • We don't claim that zero trust eliminates the need for your own security practices. You still need MFA enrollment, role hygiene, periodic access reviews, integration credential rotation.

What we do claim: when something goes wrong, the design contains the blast radius and gives you the audit trail to investigate.

Where to next