What Your AI Should Never Be Able to Do to Your Database
Before you hand any tool a database login, you should know exactly what it can do with it. The honest answer is the one most people never ask for: can it change anything? The post that started this conversation points to a specific place to look. Open the connection in Skopx Settings and find the read-only setting. Skopx reads PostgreSQL and MySQL in that mode, which means no write, update, or delete statement can run against your data. This article walks through what that means in practice, what it does and does not protect you from, and how to check it yourself.
Why the login question matters more than the model question
Most conversations about AI tools focus on how smart the model is. That matters, but it is the second question. The first question is about access. A brilliant assistant with write permission to your orders table is a larger risk than a modest one that can only look. Good intentions do not change the mechanics: a query that was meant to count rows can be written in a way that updates them, and a tool that generates SQL from plain English will sometimes produce SQL you did not expect.
Read-only access turns that risk from a matter of trust into a matter of permission. The database engine itself refuses the write. You do not have to rely on the assistant being careful, because it is not able to be anything other than careful about your data.
What read-only actually means here
When a connection is set to read-only, Skopx issues queries that retrieve information and nothing else. Questions like "which accounts have not ordered in ninety days" or "what was last month's revenue by region" become select statements. The results come back to you as tables, charts, and written answers. The underlying rows stay exactly as they were.
It helps to be precise about the boundary. Read-only protects the data in your tables from being changed or removed by the assistant. It does not make the answers correct on its own, and it does not hide the data from people who should not see it. Those are separate concerns. You still decide which credentials to create, which tables a read-only user can reach, and who on your team can open the workspace. A sensible setup gives the connection a database user with select privileges on only the schemas it needs.
How to check it yourself
You do not need to take anyone's word for it. Open the connection settings, confirm the read-only option is on, and then test it with a harmless request. Ask a question that would require a change, such as asking the assistant to mark a set of records as archived. The expected result is a refusal or an explanation that the connection is read-only. If you have database access, you can also review the database user's grants directly and confirm it has no insert, update, or delete privileges. Two independent checks, the setting in the app and the privileges in the database, are better than one.
Where read-only fits in a larger habit
Treat read-only as the default for any AI tool that touches operational data, and only widen access deliberately. When a workflow genuinely needs to write something, such as sending a summary or creating a task, design that step as a separate, explicit action that a person approves, rather than giving the analysis layer the power to edit records on its own. Keeping reading and acting apart makes both easier to audit.
The question in the first line of this piece is a good one to bring to every tool you evaluate. What would you want to hear before handing over a login? Ask it, look for the read-only switch, and verify it rather than assuming. That habit costs a minute and can save you from an afternoon of restoring data you never meant to lose.
