How should AI read your database without breaking anything?

The risk that people design for is modification and the risk that actually materialises is load. A generated query that joins several large tables without an index, or scans a table that should have been filtered, will run, will be correct, and will make the database slow for everyone else. Read-only access prevents none of this, which is why the permission decision and the performance decision are separate.

So the arrangement has four parts. A dedicated account with read-only rights, so nothing can be modified whatever is generated. A replica or a restricted set of views rather than the production tables, so load lands somewhere it does not matter and the exposed surface is chosen rather than inherited. Limits — statement timeout, row cap, cost ceiling — so a single expensive query fails rather than degrading the system. And the schema supplied as context, which is what makes the generated queries correct in the first place.

The schema point is worth expanding because it is the difference between a system that works and one that guesses. A model asked to query a database it cannot see will produce plausible table and column names, and those queries fail loudly, which is the good case. Supplied with the actual schema, including which columns mean what and how tables relate, it produces correct queries — and the descriptions matter as much as the names, because a column called status does not explain its permitted values.

Views are underrated here and solve several problems at once. A view exposes the columns you intend, excludes the sensitive ones, applies the filters that would otherwise have to be remembered, and gives the joins a name rather than requiring them to be reconstructed. A small set of well-named views is easier to query correctly than a normalised schema and is also the access boundary, which means one artefact is doing both jobs.

The output needs the same treatment as any other generated result. A query that returned rows is not a query that answered the question: the wrong filter, a missing condition or an unintended join produces a plausible number from real data, which is harder to doubt than an invented one. Where a figure matters, the query itself should be visible alongside the result so that it can be read rather than trusted.

Finally, log the queries. What was asked, what was generated, what it returned, how long it took. This is what lets you find the expensive ones, notice the ones that ran against something they should not have reached, and answer the question of where a figure came from three weeks later. It costs almost nothing and is the difference between a facility and an unaccountable one.