A support engineer is stuck on one order. The status says packed, the customer says it never shipped, and the person who knows the schema is in another meeting. The engineer points a coding agent at the production database and asks why the order is stuck. The setup box wants a connection string. Pasting it is the fastest way to get an answer, so the string goes into the chat.
The agent finds the row. Then it "fixes" the status with an update, because the question was phrased as a problem to solve and the login it was given can write. The engineer who pasted the string does not own the orders table. The payments team does. By the afternoon, nobody can list the statements that ran. The transcript has the password in it, and so does whatever log the model provider keeps.
That is the pain. An assistant that can query a database can also be the thing that changes a record. The person who connected it is often not the person who owns the data. A password that lives in the prompt is a credential the assistant keeps. The useful question is which control still lets the assistant do the job.
What you are actually handing over
A database login is a bundle of rights, not a search box. If the string belongs to the application user, the agent inherits every grant that user has: the tables the app writes, the migrations role someone added during an incident, the right to read a column the support staff are not supposed to see. The chat interface hides that bundle behind a single field labeled connection.
Two different problems get mixed together because they happen in the same paste.
The first is authority. Who is allowed to ask, and who is allowed to change a row? Those are different jobs. A question about a stuck order needs a select. Repairing the row is a decision a person makes after reading the row, with a login that is allowed to write, and with the statement visible before it runs.
The second is custody of the secret. A password in a prompt is no longer in the secret store. It is in a session other people may open, and in a request that left the building. Rotating it means finding every place it was pasted.
Why the usual tools do not supply that control
A SQL client keeps the human in the loop because the human is the one typing. The login can still be too powerful, and people do paste production passwords into desktop tools. The difference is that an update is a statement the person chose to run, in a window they can scroll. An agent chooses the next statement from a goal. The window, if there is one, shows it after the fact, or not at all.
A BI tool usually avoids this pain by never offering a write. That limit is also why it cannot answer today's stuck order. The dashboard was built last quarter. Exporting it to a spreadsheet drops the live credential and the live row together. The file is stale by the time it is attached to the ticket, and the password problem has been replaced with a copy of the data in someone's inbox.
A text-to-SQL chat wired to one database is the tool that looks like the fix. It takes a sentence and runs SQL. In practice the setup is still a connection string, often the same application user, often pasted into a config the chat can read. The product answers. It does not, as a class, hand you a separate read-only role, a statement log, and a place for the secret that is outside the prompt. If it runs with the rights it was given, an update is a successful query. The SQL client assumes a careful person. The BI tool assumes a question someone already modeled. The spreadsheet assumes yesterday's extract is enough. The chat assumes the connection you supplied is the control.
What to put in place before the agent runs
You can do this with the database you already have. None of it requires a new product.
Create a role whose only job is questions. Grant select on the schemas those questions need, and stop there. No insert, no update, no delete, no right to change grants, no ownership of the application role. Name the role after the job (agent_read is enough) so a later audit can see it.
Keep the password out of the prompt. Put it in an environment variable, a local file the process reads, or the secret store you already use for the app. If the only setup the tool offers is a text box, do not paste the production URI into it. Point the tool at a read replica or a restored copy when you have one, and use production when the question is actually about production.
Give the role to a person, not to a shared admin login several teams know. A named role can be revoked without locking the application out.
Log the statements. If you cannot list what the agent ran, you do not yet have a control. The database's own statement log, or the proxy you already run in front of it, is the list. Read it once on a quiet day so you know where it is.
Treat writes as a second step. When a row really does need to change, a person reads the statement and runs it with a login that is allowed to write. Handing the agent both roles because the second login was annoying is how the first bad update happens. If a tool cannot show you the statement before a write, it is the wrong tool for the write.
Start on a copy when the question allows it. A restored snapshot answers "what did this order look like?" without the right to change what the customer sees now. A bad select is a wrong number. A bad update is a wrong table.
Where DataTug fits
DataTug is one way to put the question on the sources the project opens. The surfaces datatug.app lists as available are the web app, AI chat, the terminal UI and CLI, the Claude Code skills plugin, and an MCP server. The sources marked as working today are SQLite, PostgreSQL, MySQL, Oracle, SQL Server, BigQuery, inGitDB, and REST APIs.
The question stays on those sources, through a surface an agent can call or a person can type into. The read-only role, where the password lives, and the statement log are still yours to set on the database. The public page does not say the agent is unable to modify rows. If the login you attach can write, the control is still the login.
Personal and public projects are free. The demo needs no account if you want to look before you point anything at your own database. When you connect an agent, the skills plugin and the MCP setup are the doors the site already documents. Set the database role first.
Pain pointsNext: The model does not know what "customer" means