Big Three

Guide

Read-only database access for Claude, Gemini and Codex

Asking a model about your data is useful. Handing it your database password is not. Big Three puts a small broker in the middle: the model asks, the broker checks and runs a SELECT, and the password never leaves your Windows vault.

Updated November 4, 2026

How a query travels

A model never opens a connection. It sends a request to the broker, a small process inside Big Three. The broker reads the password from Windows Credential Manager, opens a read-only transaction, runs the query and returns the rows, with a limit.

  1. You save a connection once. The password goes straight to the system vault.
  2. In each conversation you choose which connections the models may query. None by default.
  3. A model that is allowed to asks the broker for a SELECT.
  4. The broker checks the query, runs it in a read-only transaction with a timeout and a row limit, and returns sanitized results or errors.
  5. Every call goes to an audit log.

Step one: create a SELECT-only user

This is the layer that matters. Whatever happens above it, the database itself refuses to write. Create a dedicated user and give it only the tables the models may see. Replace the names and the password.

PostgreSQL

CREATE ROLE big_three_ro LOGIN PASSWORD 'choose-a-long-password';
GRANT CONNECT ON DATABASE mydb TO big_three_ro;
GRANT USAGE ON SCHEMA public TO big_three_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO big_three_ro;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO big_three_ro;

MySQL

CREATE USER 'big_three_ro'@'localhost' IDENTIFIED BY 'choose-a-long-password';
GRANT SELECT ON mydb.* TO 'big_three_ro'@'localhost';

Oracle

CREATE USER big_three_ro IDENTIFIED BY "choose-a-long-password";
GRANT CREATE SESSION TO big_three_ro;
GRANT SELECT ON app.orders TO big_three_ro;

Step two: connect it in Big Three

Open Databases in the sidebar, choose the engine, fill in the connection and press Save and test. The password is stored in Windows Credential Manager and is not shown back. Then, in a conversation, tick the connections the models may query.

The layers, one by one

  • A SELECT-only database user. The database refuses everything else. This is the one that matters.
  • A SQL guard. Statements that are not a plain read are rejected before they reach the database.
  • Read-only transactions. Even a query that slipped through cannot write.
  • Timeouts and row limits. A runaway query is cut off, and a huge table does not flood the chat.
  • Sanitized errors. Error messages are cleaned so they do not leak connection details.
  • An audit log. You can see what was asked.

An honest limit

The system vault belongs to your Windows user. A model that you allow to run arbitrary commands as you could read it the same way the broker does. That is why the database user should only have SELECT, and why models start read-only. The full threat model is in SECURITY.md.

Questions about database access

Can a model see my database password?

No. The password goes from the form straight into Windows Credential Manager. It is never shown back, never written to a log and never sent to a model. The broker reads it only at the moment it opens a connection.

Is a SQL filter enough to keep the database safe?

No, and Big Three does not rely on it alone. The layer that matters is a database user that can only SELECT. The SQL guard, read-only transactions, timeouts and row limits are extra layers on top of that.

Which databases are supported?

PostgreSQL, MySQL and Oracle. Models can run SELECT queries on the connections you allow in each conversation; Gemini cannot use the database tools yet.

Keep reading