Is pasting my schema into ChatGPT to get SQL safe?

Your schema leaves the company, and the generated query reaches you without passing any safety layer; running it is entirely on you. Fine for personal experiments, not recommended for company data.

How do I create a read-only database user?

With each engine's GRANT command: in PostgreSQL, for example, you define a role holding only SELECT privileges. It takes five minutes and is good security practice regardless of AI.

How much can I trust AI-generated SQL?

Look at the measurement. We test PerSight's generation against hundreds of real questions on four engines; result accuracy is 94% on typical business domains, with the method published openly. If anyone claims 100%, ask for their method.

If I cannot set up all these controls, should I avoid it entirely?

Do not use it on company data without at least the first two: a read-only user and a visible query. Those two alone contain most of the risk.

← All postsThe PerSight Team · Last updated: July 25, 2026 · 6 min read

Is AI-Generated SQL Safe? The Real Risks and How to Contain Them

AI SQL generators and ChatGPT-written SQL are everywhere; is that safe on company data? Four real risks and a concrete control for each: read-only users, visible SQL, data locality, and measurement.

Having AI write SQL is now ordinary: some paste table structures into ChatGPT, others use an AI SQL generator. Which is why the question keeps coming up: is this safe on a company database? Short answer: yes with the right controls, no without them. Let's walk through the four real risks.

Risk 1: Can a generated query change data?

The biggest fear: the model produces an UPDATE or DELETE and someone runs it without thinking. The control has two layers. First, on the database side: connect with a user that only holds SELECT privileges, so even a bad query gets rejected by the engine. Second, on the tool side: serious tools block anything but SELECT at generation time. PerSight applies both; writes are technically impossible.

Risk 2: Does my data reach the model?

The moment you paste a schema or sample rows into ChatGPT, that content has left the company; at many organizations that alone violates policy. The correct setup sends the model only the schema (table and column names) and never row data. The question to ask any tool you evaluate is blunt: "What exactly do you send to the cloud, and can you show me?" PerSight shows it verbatim in an in-app transparency panel.

Risk 3: What if the query is wrong and nobody notices?

This is the sneakiest risk because there is no error message: the query runs, a number comes back, and the number is wrong. Decisions get made on it. Two controls work together: the generated SQL must always be visible and editable (no black boxes), and the tool's accuracy must be measured regularly with an open method. Tying business decisions to a tool that does not measure or publish its accuracy is weighing gold on an untested scale.

Risk 4: Malicious requests through natural language

Prompt injection tops OWASP's security list for LLM applications: a user (or text embedded in data) may try to talk the model into something it should not do. The defense is not trusting the model's manners; it is hard gates the model cannot pass regardless of what it generates: a read-only user, a block on non-SELECT statements, and a visible query that goes through human approval. With the gate layer in place, a fooled model produces no consequences.

Frequently asked questions

Is pasting my schema into ChatGPT to get SQL safe?: Your schema leaves the company, and the generated query reaches you without passing any safety layer; running it is entirely on you. Fine for personal experiments, not recommended for company data.
How do I create a read-only database user?: With each engine's GRANT command: in PostgreSQL, for example, you define a role holding only SELECT privileges. It takes five minutes and is good security practice regardless of AI.
How much can I trust AI-generated SQL?: Look at the measurement. We test PerSight's generation against hundreds of real questions on four engines; result accuracy is 94% on typical business domains, with the method published openly. If anyone claims 100%, ask for their method.
If I cannot set up all these controls, should I avoid it entirely?: Do not use it on company data without at least the first two: a read-only user and a visible query. Those two alone contain most of the risk.

If you would rather have these controls as defaults than build them one by one, that is PerSight's baseline: non-SELECT generation blocked, the query always visible, only schema and question sent to the cloud, and accuracy measured and published. The persight.ai/en/security page was written for your IT team.