Data isolation & retention

Tenant isolation is enforced at the database layer, not in application code. Deletion is permanent. Retention windows are explicit and defensible.

Database-enforced Row Level Security

Beakr enforces tenant isolation at the database layer, not in application code. Even if application logic contained a bug that omitted a tenant filter, PostgreSQL itself would prevent cross-tenant data access.

How it works

Every query runs under a restricted database role (beakr_app) that is subject to Row Level Security policies.
Before any query executes, the authenticated user's organization ID is bound to the database session via transaction-scoped configuration (SET LOCAL). This context is locked to the current transaction and cannot leak between requests.
PostgreSQL RLS policies automatically filter every SELECT, INSERT, UPDATE, and DELETE to the authenticated organization. There is no way to query another organization's data, even with raw SQL.
Fail-closed design. If tenant context is missing, queries return an error — not unfiltered data.

Role separation

Database role	Purpose	Can bypass RLS?
`beakr_app`	All application queries	No
`beakr_migrator`	Schema migrations only	Cannot read tenant data
`beakr_admin`	Infrastructure operations only	Restricted to infra tasks

This approach provides isolation guarantees that exceed what most single-tenant deployments offer, where a single database superuser typically has unrestricted access to all data.

Organization model

Each customer operates within their own organization. Organizations are fully isolated:

All resources (projects, files, workflows, connectors) are scoped to an organization.
Users belong to one or more organizations with explicit role-based membership.
Cross-organization data sharing requires explicit access grants and is auditable.
Personal organizations are available for individual users.

Retention periods

Data type	Retention	Controlled by
User files and documents	Until user deletes	User
Projects and workspaces	Until user deletes	User
Workflow configurations	Until user deletes	User
Connector configurations	Until user disconnects	User
Application audit logs	90 days	System
AWS API audit logs (CloudTrail)	365 days active, 2 years archive	System
Database backups (production)	30 days	System
S3 version history	90 days	System

Deletion

Beakr performs hard deletes — deleted data is permanently removed, not soft-deleted or marked inactive.

When a user deletes a resource:

File content is removed from S3.
Metadata, search vectors, and embeddings are removed from the database.
All related records (versions, citations, access grants) are cascade-deleted.
An audit log entry is created.

Account deletion removes all user data across all projects, revokes all connector connections, and removes all organization memberships. Audit logs are retained for 90 days per policy.

Backup caveat

Deleted data may exist in automated backups for the backup retention period (30 days in production). After backup retention expires, deleted data is permanently unrecoverable.

Authentication & access control

Authentication

User authentication (Clerk). JWT-based authentication through Clerk, a SOC 2 Type II certified identity provider. Supports email/password, social login, and multi-factor authentication (MFA).
API key authentication. Keys use the bk_live_ prefix, are generated with 256-bit entropy, and validated via constant-time comparison to prevent timing attacks.

Role-based access control

Role	Capabilities
Viewer	Read-only access to shared resources
Member	Create and manage own resources
Admin	Manage team members and settings
Owner	Full control including billing and deletion

Access is evaluated at multiple levels: Organization (membership and role), Space (team or lab groupings with inherited permissions), and Project (granular access grants for individual projects — read, write, share). Space administrators inherit access to all projects within their space. Cross-organization sharing uses explicit, auditable access grants.

CSRF protection

All state-changing requests are protected against cross-site request forgery using Origin and Referer header validation.

Data export

Users can export their data at any time:

Individual file download.
Bulk export by project.