Security overview
How Breno protects data: isolation enforced by the database, one access rule, encryption of secrets, two-factor authentication, an append-only audit log, and what is not claimed.
Security here is a set of specific mechanisms you can check, not a badge. Each one below says what it does, and where it stops.
Isolation between workspaces#
Every table that holds workspace data has row-level security in the database, keyed on the active workspace. A query that forgot to scope itself still cannot return another workspace's rows. Production refuses to start unless this is enforced and the application's database role is not a superuser. The test suite runs a second time as a non-superuser to make the policies load-bearing, and a test fails by name if a table with workspace data is neither covered nor deliberately exempt.
One access rule#
Every read goes through one shared rule that applies workspace, space, sensitivity and privacy, and every write through a matching rule. No language model takes part in deciding access. See How access works.
Secrets#
- Credentials for connected sources and keys for your own AI accounts are encrypted at rest (AES-GCM) and never returned to the browser.
- Production refuses to start without the encryption key, the signing secret, and an enforced database policy.
- Webhooks from Slack and GitHub are signature-verified before they are acted on.
- Passwords are stored hashed, and sessions are revocable.
Authentication#
- Two-factor authentication with an authenticator app, recovery codes, and an option to require it for the whole workspace.
- Sessions can be listed and ended. A personal token dies the moment its owner loses access.
- Tokens are scoped, can only call a short list of operations, and are rate limited. See Tokens.
An audit trail that cannot be edited#
The audit log is append-only, enforced by the database for every role, so history survives the thing it describes. See Audit log for what it records, and what it does not yet.
Deleting means deleting#
Deleting a workspace removes its data through a single operation that reaches every table carrying it, plus its files, graph, and cached data, and writes a deletion receipt. A purge test seeds every table and proves nothing is left. See Delete your data.
Data in transit and at rest#
TLS is enforced in production. Encryption at rest for the main database and object storage depends on how the deployment is configured and is not enforced by Breno's code. If you run Breno yourself, enable it.
What leaves#
Only the text a model needs leaves an instance, to the provider the operator configures, and the optional services you turn on. Error tracking is opt-in and scrubbed. See Data flow.
How it is tested#
Security rules are mutation-checked: remove the rule, confirm the test fails, restore it. Read paths are guarded by a test that fails if a new one skips the shared rule.
What is not claimed#
- No certification. Breno is not SOC 2 or ISO 27001 certified. A control mapping exists as evidence for an audit; it is not one. See Compliance.
- The audit log does not yet cover every action. See Known limits.
- Source permissions are not read from connected tools.