Access control

Last updated: 2026-04-11 • ← Security program

Backbuild enforces access control at every layer of the platform. Authorization is evaluated on every request, multi-tenant isolation is enforced in the database, and privileged access is limited, logged, and reviewed on a recurring schedule.

Role-based access control

• Organization-scoped roles: roles and permissions are defined per organization. A user's privileges in one organization have no effect on another.
• Role catalog: the platform ships with a set of well-defined roles (such as owner, admin, member, billing, analyst) and supports custom roles built from granular permissions where the subscription plan allows.
• Permission checks: every write operation and every privileged read evaluates the caller's organization membership, role, and permission set before proceeding.
• API surface: authorization is enforced in a central middleware layer so that individual handlers cannot accidentally bypass checks.

Multi-tenant isolation

• Row Level Security: every customer-facing data table has Row Level Security policies that restrict reads and writes to rows belonging to the authenticated user's organization.
• Defense in depth: application-layer authorization, parameterized database calls, and RLS all enforce the tenant boundary independently. A bug in any single layer cannot result in cross-tenant data exposure.
• Never disabled: RLS is mandatory. Disabling a policy to work around a bug is not permitted. When a legitimate operation is blocked, the policy or the code is fixed instead.
• Shared infrastructure, isolated data: customers share compute and storage infrastructure but their data is logically isolated. Physical or dedicated-tenancy deployments are available on request for customers with specific requirements.

Least privilege

• Database roles: application database roles are granted only the privileges required to execute the stored procedures they need. No application role has broad SELECT or superuser access.
• Stored procedures: API code interacts with the database exclusively through stored procedures that perform their own authorization. Raw SQL queries from application code are not permitted.
• Production access: human access to production infrastructure is limited to a small group of authorized operators, requires MFA, and is logged.
• Service accounts: machine identities receive narrowly scoped permissions and are rotated on a scheduled basis.

Access reviews

User and administrative access is reviewed quarterly. The review covers human accounts (including contractors and vendors), service accounts, and any elevated or break-glass access. Outcomes are recorded in an internal runbook and fed back into the access provisioning workflow. Material findings are tracked through remediation.

Separation of duties

• Administrative and operational duties are separated where the platform permits, so that a single individual cannot unilaterally introduce and approve a change.
• Code changes require peer review through pull requests before merge.
• Production deployments are automated through auditable pipelines; ad-hoc direct changes to production are discouraged and, when required, must be logged and reviewed.
• Security-sensitive configuration changes go through a documented approval path.

Privileged access monitoring

All privileged actions — administrative logins, role changes, policy updates, break-glass usage — are logged with user attribution, correlation identifiers, and timestamps. Logs are forwarded to the central audit store and monitored for anomalous patterns.