Shift note: SQL drafts stay outside production

The model writes a draft, not a database command

A language model can turn “show last month’s orders by region” into SQL. That is useful, especially when you know the business question but not the database syntax. The safety boundary is simple: treat the result as an untrusted draft, not as permission to run it.

A query can look convincing and still use the wrong table, count customers twice, expose private columns, or scan an expensive amount of data. Safe SQL generation therefore needs two separate checks: whether the query is allowed, and whether it answers the question correctly.

Give the model a small, accurate schema

The schema is the database’s map: table names, column names, data types, and relationships. Give the model only the part it needs. Include business definitions, such as whether “revenue” means paid invoices or all orders, and which timezone defines a reporting day.

Do not paste production records, credentials, or unrestricted database exports into a prompt. If examples help, use synthetic data. A curated reporting view can make this easier by exposing approved columns and hiding unnecessary complexity.

Ask for a specific SQL dialect, such as PostgreSQL, and request separate fields for the SQL draft, parameter names, assumptions, and any clarification needed. If the request is ambiguous, let the model ask a question instead of guessing.

Keep user values out of SQL text

Suppose someone asks for orders belonging to a particular customer. The model should draft a query with a placeholder, such as SELECT order_id, total FROM reporting_orders WHERE customer_id = :customer_id LIMIT 100. Your database driver may use a different placeholder syntax.

The application then binds the customer identifier through the driver’s parameter API. It must not insert the value by joining strings. Parameter binding keeps values separate from SQL instructions. This helps prevent SQL injection through those values, but it does not make an arbitrary model-generated query safe.

Table names, column names, and sort directions usually cannot be bound as values. When those must vary, map the request to a fixed allowlist in application code. Tenant identifiers and access scopes should come from the authenticated session, not from the model’s judgment.

Put a policy gate before the database connection

A prompt saying “only generate safe SQL” is guidance, not enforcement. Validate every draft before execution with a dialect-aware SQL parser and explicit rules. Searching for dangerous words is not enough.

• Accept exactly one statement and restrict it to an approved read-only query shape.
• Check every referenced table, column, and function against an allowlist, including references inside nested queries and common table expressions.
• Reject writes, schema changes, administrative commands, and features outside the supported subset.
• Require parameter placeholders for external values and verify that supplied parameters match the expected names and types.
• Apply result limits, execution timeouts, and database-specific resource controls independently of the generated SQL.

Read-only does not automatically mean harmless: queries can still expose sensitive data or consume substantial resources. Use a dedicated database role with minimal permissions, and enforce row-level access in the database or another trusted layer. Start with a reporting replica or isolated test environment where appropriate.

Check the answer, not just the syntax

A valid query can still produce a misleading report. Joins can multiply rows, missing filters can include canceled orders, and date boundaries can shift totals. Test familiar questions against known answers before expanding access. For unfamiliar or sensitive requests, show the proposed interpretation and require human review.

Treat retrieved text and database content as untrusted data too. A note inside a record telling the model to ignore its rules must not change execution policy. Log validation decisions and query metadata without unnecessarily recording sensitive values.

Choose model access without moving the safety boundary

If you want to test SQL drafting across model families, Relay365 is a pay-as-you-go relay desk that fits that evaluation workflow. You could try Gemini 2.5 Flash against your own approved test cases. Create a Relay365 account when you are ready to experiment, while keeping validation and database credentials in your application.

The operating rule stays the same regardless of provider: the model proposes SQL; trusted code decides what can run.