I need to build a guard that prevents the LLM from generating 'DELETE' or 'DROP' commands in a Text-to-SQL tool. Has anyone successfully used Guardrails AI to enforce a read-only schema? I’m curious if it's better to use a regex-based validator or a more complex semantic check to catch obfuscated malicious queries.
3 answers
For SQL safety, a hybrid approach is best. Use a regex-based validator for immediate blocking of forbidden keywords like 'DROP' and 'TRUNCATE'. However, since attackers can use payload splitting or encoding to bypass simple string matches, you should also implement a custom Guardrails AI validator that parses the generated SQL using a library like sqlglot. This allows you to inspect the Abstract Syntax Tree (AST) of the query. By checking the statement type at the AST level, you can programmatically ensure that only 'SELECT' statements are allowed, regardless of how the user tries to disguise the command in the natural language prompt.
Have you considered the 'Fix' strategy where the guard automatically rewrites the query to be safe instead of just throwing an error to the user?
The Guardrails Hub actually has a few pre-built SQL validators now. It might save you time to check those out before building one from scratch.
Good call, Danielle. I found a SQL-parser validator on the Hub yesterday that handles basic read-only enforcement exactly as Megan described.
I thought about it, but rewriting SQL feels risky. If the guard misinterprets the intent and changes a filter, the user might get the wrong data without knowing why. I prefer the 'Exception' strategy for now, where we just block the execution and log the attempt for our security team to review.