DBHub

DBHub connects with one database credential supplied by the operator (the DSN) and uses it for every tool and every client. In the README's lead setup (HTTP transport), access control on the HTTP endpoint is not locked down. Read-only access is possible only through a TOML file; the old --readonly flag now exits with an error.

As a tool server, DBHub's job is to tell the host which calls are dangerous. By default the single execute_sql tool both reads and writes, and it is honestly flagged as destructive, so a host can only gate all SQL or none. DBHub has a strong opt-in read-only mode: a per-tool TOML setting that rejects non-read statements and also runs them in a read-only database transaction, with matching read-only annotations. Because it is off by default and cannot be set from the command line, a wrongly approved call in the shipped setup can drop or delete production data with no undo.

The default execute_sql tool takes arbitrary SQL with no validation, row limit or timeout, against any table the credential can reach. Narrower options exist: TOML custom tools use parameterized statements with typed and enumerated arguments, search_objects validates and caps its inputs, and the opt-in read-only mode combines a keyword classifier with a database-level read-only transaction. None of these is the default, so a misused tool in the shipped setup can read or rewrite the whole database.

Raw SQL from the model is code, and DBHub adds no isolation around it: statements run in the database with the full privileges of the configured account, and SQLite databases are opened inside DBHub's own process. DBHub itself starts no subprocesses and evaluates no JavaScript. What a statement can reach depends entirely on the database account: with a superuser or highly privileged account, server-side features (file reads and writes, program execution) are within reach in the default write-enabled mode.

Database contents are untrusted input: any row can carry instructions aimed at the model reading it. DBHub returns results as structured JSON that names the source and the SQL each result came from, which helps a host tell data from metadata, but nothing marks the rows as untrusted. Its read-only mode would drop the state-change leg, but it is off by default. In the README's HTTP setup, a hijacked session can delete or alter shared data that every other client of the server also uses, so the worst case is rated at the bottom.

DBHub has no memory, retrieval store, or instruction files. The TOML config is loaded only from an explicit --config path and is hot-reloaded from that path. However, in TOML mode and in the env-var fallback mode, DBHub silently loads a .env file from the current working directory first, which can supply the database DSN, switch the transport to HTTP, or disable the DNS-rebinding check when those values are not already set. The README's --dsn invocation does not load it.

DBHub loads no third-party code at runtime: there is no plugin system, no MCP client, and no model-driven package installs. Database drivers and optional cloud SDKs are fixed, string-literal imports that ship with the package, which is the project's own build supply chain and out of scope here.

Database passwords are redacted when DSNs appear in startup logs and connection errors, the web API omits passwords and SSH credentials, and there is no telemetry. Credentials come from command-line flags, environment variables, or config files in plain text, and the SSH tunnel and the HTTP-mode request log (which holds full SQL text) do not fully protect sensitive data.

Every tool call is recorded with its tool name, SQL, timestamp, duration, success and error, and the client's User-Agent. The record lives only in memory, keeps the last 100 calls per source, and disappears on restart; nothing is written to disk or shipped elsewhere, and tool calls are not logged to the console. A model can push its own earlier calls out of the record simply by making more calls.

search_objects has a server-enforced result cap (default 100, maximum 1000). The main execute_sql tool has no row limit and no query timeout unless the operator sets max_rows and query_timeout in a TOML file, and neither can be set with --dsn. Tool handlers ignore MCP cancellation, so a cancelled or abandoned query keeps running on the database.