Security
The security model, in plain words
bzora is a tool you point at production. Here is exactly what it does to keep that safe, what it never does, and where its limits are.
What never happens
- Your passwords are never written to a file.
- Your rows are never sent anywhere. Not to us, not to an AI provider.
- There is no telemetry and no analytics.
- There is no account and no cloud sync.
- An unknown SSH host is never silently trusted.
- A weaker connection mode is never chosen silently. The one default is for
+sshURL imports, described under the network. - Nothing from a database is ever rendered as HTML.
Secrets
Database passwords, SSH passwords, key passphrases and AI API keys are stored in the operating system's keychain: macOS Keychain, Windows Credential Manager or the Linux secret service. The connections file on disk contains none. A password found in a pasted URL is moved to the keychain before anything is saved, and error messages from a failed connection are scrubbed of the secret.
The network
- Encryption is on by default. PostgreSQL uses
verify-full. MySQL uses verified TLS. SQL Server encrypts and verifies the certificate. You can opt a single connection down, and bzora does not do it for you, with one exception: importing a+sshURL sets the connection toprefer(TLS if the server offers it, without verification), because a tunnelled database usually listens on localhost without TLS and the SSH hop is already encrypted. You can change it in the connection form. - SSH tunnels check host keys strictly against
~/.ssh/known_hosts. An unknown or changed host is refused. Key file, ssh-agent, default keys and password are supported. - Old MySQL password hashes (pre-4.1) are not supported, on purpose.
Edits and structure changes
- Grid edits are staged. You can review the exact statements before any of them runs.
- A save is one transaction: all of it, or none.
- Updates and deletes address rows by primary key. A table with no key cannot be edited in the grid.
- Structure changes are previewed as SQL, and run only when approved.
- Filters, sorting and edits bind values as parameters and quote identifiers. A value you type cannot become SQL.
The review covers grid edits and structure changes. SQL you type in the editor runs when you run it.
Read-only
Mark a connection read-only and bzora opens it so the database refuses writes.
| Engine | How read-only is enforced |
|---|---|
| PostgreSQL | The session starts with default_transaction_read_only on, and the simple
query protocol (which can chain statements) is never used. |
| MySQL and MariaDB | The session is read-only, and multi-statement mode is off. |
| SQLite | The file is opened read-only. ATTACH and VACUUM are refused,
since they can write other files. |
| SQL Server | SQL Server has no read-only session, so bzora itself blocks writes. This guards against mistakes, not against a determined user. |
The window also hides every editing, import, restore and structure control on a read-only connection.
The honest limit. A read-only connection protects you from mistakes. It is not
a permission system. A user who can run SET default_transaction_read_only = off on PostgreSQL can undo it. The guarantee is
a database user that has only read rights. bzora makes the safe setup easy. It does not replace
it.
AI and MCP
The assistant writes SQL and never runs it. It is off until you configure it. What it sends: your question, the dialect, the current database name, and the names, types and keys of your tables. It never sends rows. A local model means nothing leaves your machine. API keys stay in the keychain. More on the assistant.
MCP. bzora --mcp lets Claude Desktop, Cursor or another MCP client
query a connection you have chosen.
- Off for every connection until you turn it on. A production connection asks twice.
- Every query runs on a read-only connection, in a read-only transaction that is rolled back.
- One statement at a time, and it must read.
- It never returns a host, a user or a secret.
- SQL Server is never shared, because it cannot enforce read-only.
The limit. The database user bzora connects with still has its own rights. A privileged user can read more than you might expect, even in a read-only session. Give MCP a read-only database user.
What leaves your computer
| What | When | Where to |
|---|---|---|
| License check | On activation, and in the background | Lemon Squeezy |
| Update check | At start | dl.bzora.io (a small version file) |
| Database traffic | Only to the databases you configure | Your own servers |
| AI requests | Only if you enable the assistant | Your local model, or the provider you chose. Names only. |
That is all. No crash reports, no usage statistics.
What is kept on disk
Stored in your user config folder, readable only by you:
- Saved connections, without secrets.
- Per-database tabs and query text, for session restore.
- Per-database query history and favourites. Statements that set a password are never written.
- License state.
Query text and history are plain files. Anyone who can read your user folder can read them. If that matters, use full-disk encryption.
Reporting a problem
Send security reports to [email protected]. We read every one.