The Promise and Danger of NL-to-SQL

Allowing non-technical users to query database tables using natural language (e.g., 'Show me total sales by region last month') is incredibly powerful. However, letting an LLM generate and execute SQL directly on your database is highly dangerous. Prompt injection, database corruption, and data leaks are real risks that must be guarded against.

Security Best Practices for SQL Agents

To run NL-to-SQL workflows safely in production, implement the following guardrails:

1. Read-Only Database Connections: The database user credential used by the AI agent must have strictly read-only permissions (SELECT). It must have no write, update, delete, or schema alteration capabilities (no INSERT, UPDATE, DROP).
2. Schema Minimization: Do not feed your entire database schema to the prompt. Create specific SQL views that expose only the necessary tables and columns, masking sensitive columns like passwords, API keys, or personal health records.
3. Query Sanitization and Syntax Verification: Run the generated SQL through a parser to ensure it does not contain forbidden keywords (like GRANT, UNION with system tables, or nested administration tasks) before executing it.

The Human-in-the-Loop Safeguard

For sensitive operations or high-complexity queries, present the generated SQL query and a preview of the affected data to a human administrator for approval before running it. Combining these strategies ensures safety while maintaining a delightful user experience.