# Security

> The real security practices Scribase ships, stated honestly including what is not yet certified.

Source: https://scribase.com/security

## Row-level security, linted for cost

Access control lives in Postgres row-level security policies, and Scribase lints those policies for cost so tenant isolation stays both correct and fast. Security that is too slow to keep on tends to get turned off.

## Encryption in transit and at rest

Traffic to the data-plane and control APIs is served over TLS, and stored data and backups are encrypted at rest. Keys and secrets are managed by the platform, never checked into your code.

## Least-privilege operator model

The control plane runs on a least-privilege role model and never requires cluster-admin inside your workloads, whether you run on managed Scribase or bring-your-own-cloud.

## Secret-scrubbed preview branches

Preview environments are scrubbed of production secrets and swept on a TTL when a pull request closes, so a stale branch never becomes a credential leak.

## Auditable, idempotent operations

Every mutation runs through a durable executor, carries an idempotency key, and returns an operation ID, so changes are safe to retry and traceable to who or what made them.

## Verified restore with evidence

Recovery is proven, not assumed: each verified restore ships row-count parity, SHA-256 checksums, policy parity, and a real login proof.

## Portability as a safeguard

scribase export produces a checksummed bundle that boots elsewhere. Being able to leave with your whole stack is itself a security property — you are never trapped with a single provider.