How do I handle confidential projects inside an AI platform?

Per-workspace keys by default

Confidential projects — M&A deals, executive compensation, unannounced products, legal matters — cannot share an encryption boundary with day-to-day work. bRRAIn's Vault implements envelope encryption where each Workspace has its own data encryption key, wrapped by a master key or an external HSM/KMS. A confidential-project workspace is cryptographically isolated from the rest of the company. Compromising a general-purpose workspace does not leak the confidential one; the keys are genuinely separate.

Admins cannot read without policy

A common failure of "confidential" folders in typical SaaS is that a platform admin can always read them in emergency. bRRAIn's architecture is explicit: even a global admin cannot read a confidential workspace without an explicit policy grant evaluated by the Security Policy Engine. That grant is time-limited, logged, and attributable. Break-glass access is possible but visible. This is what allows legal counsel to run a matter inside the platform — their privilege is not at risk of incidental exposure because access requires deliberate policy approval.

Role elevation with human approval

When a confidential project needs a collaborator added, bRRAIn's Control Plane enforces a role elevation workflow. The project lead requests the addition, the Security Policy Engine routes it for approval, and the approval is logged with the justification. The new collaborator gets workspace-scoped access, not global. When their contribution ends, the elevation is revoked automatically or on schedule. This mirrors how highly regulated industries (defense, pharma, legal) already handle confidential-project staffing; bRRAIn encodes the workflow as policy rather than relying on human discipline.

Audit that survives the project

Confidential projects often outlive their confidentiality — an M&A deal closes and the workspace becomes part of standard operations. The audit trail needs to survive that transition. bRRAIn's Security Policy Engine logs are immutable and queryable years later. The Vault retains the encrypted history even after the keys are rotated or the workspace is reclassified. Three years after the deal, legal can still answer "who had access to this workspace during Q2 of the closing year," which is often the question that matters in a dispute.

External counsel and advisor access

Confidential projects usually involve external parties — outside counsel, investment bankers, auditors. bRRAIn supports this through guest-tier roles in the Control Plane with workspace-scoped access and separate audit tagging. The external party sees only what you publish to them; their queries are tagged distinctly in the audit log; access revokes on project close. The MCP Gateway restricts what tools they can invoke — typically read-only document access and no outbound communication tools. You get the collaboration without widening the trust boundary.

Relevant bRRAIn products and services

• bRRAIn Vault — envelope encryption with per-workspace keys for cryptographic project isolation.
• Workspaces — the isolation unit for a confidential project with its own keys and policies.
• Control Plane — enforces role elevation workflows and guest-tier access for external collaborators.
• Security Policy Engine — logs admin break-glass access and role elevations immutably.
• MCP Gateway — restricts which tools external parties can invoke inside a confidential workspace.
• Legal use case — deep-dive on running privileged matters inside the platform.