For database chat, enforce read-only access below the agent

A database assistant’s system prompt can say “read only.” That is not the same thing as a read-only system.

Trinetro Labs’ October 2 setup guide recommends creating a database user that can only read before connecting a natural-language query tool. It also recommends limiting that identity to the tables the tool actually needs. Those are ordinary database controls, but that is precisely why they are stronger than a behavioral promise made to an AI agent: the database enforces them even when the model, prompt or orchestration layer behaves unexpectedly.

Put the hard boundary at execution

The guide describes three broad approaches: asking a general assistant to write SQL for a person to run, connecting a text-to-SQL layer that generates and executes queries, or using a deterministic engine that profiles schema and constructs queries from rules. Their implementation details differ, but the deployment question is the same: what can the execution identity actually do?

A production connection should therefore start with two restrictions. First, use credentials that cannot write, so an incorrect tool call cannot modify or delete data. Second, scope those credentials to the required tables rather than exposing the entire database. Trinetro also advises checking where credentials are stored, how they are removed, and whether access can be granted per member.

That separation matters because application-level guardrails and database permissions answer different questions. The application can decide which tool to call. The database decides whether the requested operation is permitted. Teams should test the latter directly: attempt a write with the same identity used by the assistant and confirm that the database rejects it.

Read-only does not make an answer correct

The guide does not treat access control as an accuracy mechanism. It separately recommends checking the first answer against a known number and retaining a readable trace of the tables and joins used. That is the right division of labor. Read-only credentials constrain damage; validation and provenance help detect a plausible but incorrect result.

Trinetro is describing its own product, including claims about deterministic answers and credential deletion, so buyers should verify those behaviors rather than accepting the vendor’s description as independent evidence. The useful lesson does not depend on the vendor, however: enforce the most important safety property in the database itself, then evaluate the analytical answer above that boundary.

A prompt is policy text. A restricted database identity is an enforcement mechanism. Production teams need both, but they should not confuse them.