Security

Our Commitment to Security

BrAIn is built for enterprise customers operating in knowledge-intensive domains — including healthcare, legal, and finance. Security is not an afterthought; it is a core design constraint at every layer of the platform. This page describes the security controls, architectural decisions, and operational practices that protect your Organization's data and AI agents.

1.1 Multi-Tenant Isolation

BrAIn enforces strict tenant isolation through a dedicated-database-per-organization model:

• Every Organization receives its own isolated database instance. There is no shared schema or co-mingled data between tenants.
• Tenant identity is resolved from a subdomain prefix on every inbound request, enforced at the API gateway before any data access occurs.
• A lightweight master database stores only routing metadata (organization names and subdomains) — no business or user data lives there.
• Knowledge Base vector embeddings in Milvus are stored in per-Organization collections, preventing any cross-tenant information leakage at the AI layer.

This architecture means that a misconfiguration or compromise affecting one tenant cannot expose another Organization's data.

1.2 Authentication — OAuth Only

The Platform uses OAuth 2.0 exclusively (Google and Microsoft). We do not store passwords. This means:

• Credential management risk is delegated to established identity providers with mature security practices.
• Brute-force and credential-stuffing attacks against BrAIn have no surface to exploit.
• Users benefit from their OAuth provider's MFA, anomaly detection, and device trust features.

2.1 Role-Based Permissions

Every action in the Platform is governed by role-based access control (RBAC). The three roles — USER, ADMIN, and SYSADMIN — carry narrowly scoped permissions:

Permissions are resolved from the database on each request and cached via an in-memory role permission cache to balance security correctness with performance.

2.2 Agent Access Control

ADMIN users control which Users have access to which Agents. Agents are not universally accessible within an Organization — access is explicitly assigned, supporting a principle-of-least-privilege model for AI deployments.

2.3 Agent Activation Workflow

All Agents pass through a review gate before they go live: DRAFT → PENDING → ACTIVE. The SYSADMIN team reviews Agent configurations — including guardrails and forbidden actions — before activation. This prevents misconfigured or potentially harmful Agents from being deployed without oversight.

3.1 Data in Transit

All communication between clients and the Platform is encrypted using TLS. Internal service-to-service communication within the platform infrastructure is also encrypted in transit.

3.2 Data at Rest

Organization databases, vector store collections, and file storage are encrypted at rest. Encryption is managed at the infrastructure layer using industry-standard AES-256.

4.1 Network Segmentation

Internal services (AI engine, vector database, LLM inference) are not directly reachable from the public internet. All external traffic routes through the API gateway. Internal operational endpoints are protected by an IP allowlist filter that restricts access to authorized operator CIDRs.

4.2 Service Discovery

Internal services register and discover each other through a private service registry. The registry is not exposed externally.

4.3 Rate Limiting

Authentication endpoints are protected by a rate limiting filter that restricts repeated request attempts and helps prevent brute-force and abuse scenarios.

4.4 Secrets Management

Service credentials, API keys, and database passwords are not committed to source control. They are injected at runtime via environment variables. Infrastructure secrets are managed through a secrets management process separate from application code deployment.

5.1 Least Privilege Operations

BrAIn team members with SYSADMIN access to production environments are limited to those with an operational need. SYSADMIN actions within the Platform are scoped to support functions — Organizations cannot be destructively modified without deliberate action.

5.2 Dependency Management

Dependencies are pinned and reviewed. The build pipeline does not use floating version ranges for production dependencies in order to avoid supply-chain surprises.

5.3 Security Testing

BrAIn follows secure development practices, including input validation at system boundaries, parameterized queries to prevent SQL injection, output encoding to prevent XSS, and CSRF protection as described above. Security reviews are part of the development process for changes to authentication, data access, and API boundaries.

5.4 Incident Response

In the event of a confirmed security incident affecting customer data, BrAIn will:

1. 1. Contain the incident and prevent further exposure.
2. 2. Investigate the scope and root cause.
3. 3. Notify affected Organizations within the timeframe required by applicable law and contractual obligations.
4. 4. Provide a post-incident summary of findings and remediation steps.

If you discover a potential security vulnerability in the BrAIn platform, we ask that you disclose it responsibly. Please contact our security team directly before publishing or sharing details publicly:

We will acknowledge your report within 3 business days and work with you to assess and remediate the issue. We do not take legal action against good-faith security researchers who follow responsible disclosure practices.