You’ve built an AI agent that can write poetry, plan your vacation, and explain quantum physics. But the moment it needs to query your database, you’re one line of string concatenation away from a catastrophe. SQL injection is the silent killer of AI-native applications, and most developers are still ignoring it.
Federico, a seasoned Python developer, saw the same pattern over and over. Teams would build beautiful LLM-powered features, then glue them to their database with raw SQL strings generated by the AI. It worked—until it didn’t. A single malformed query, a single malicious prompt injection, and the whole database is compromised.
So he built filtersql—a dependency-free Python library that compiles declarative JSON payloads into safe, parameterized SQL. No ORM. No massive framework. Just a 200-line compiler that does one thing and does it perfectly.
Here’s the radical idea: The safest line of code is the one you never write. Filtersql doesn’t give your AI agent a SQL gun. It gives it a structured JSON menu. The agent can only order from the menu—no freeform text, no injection, no surprises.
Why ORMs Are the Wrong Answer
When I first heard about this, I thought: “Why not just use an ORM?” Because ORMs are designed for humans writing queries, not for AI agents generating them dynamically. They’re bloated, slow, and they still allow raw SQL escapes. Filtersql takes a different approach: it treats the query as a data structure, not a string.
Your AI sends a JSON like this:
{"filter": {"field": "status", "op": "eq", "value": "active"}}Filtersql compiles it into parameterized SQL: WHERE status = ? with a bound parameter. No interpolation. No injection. The agent never touches the SQL dialect.
The Twist: Less Code, More Security
Here’s the contrarian truth that most security teams miss: Adding more layers of protection often introduces more vulnerabilities. Filtersql is minimal—it has zero dependencies. That means a smaller attack surface, easier audits, and faster performance. Federico proves that when it comes to AI and databases, minimalism is a security feature.
You don’t need a complex ORM or a database firewall. You need a simple, auditable compiler that translates one safe format into another safe format. Filtersql is the missing link between AI agency and database security.
I’ve seen firsthand how teams struggle with this. They build a demo that works perfectly, then spend weeks securing it. Filtersql eliminates that entire phase. Your AI agent can query any table, any column—but only through the filter grammar. It’s like giving a toddler a locked cabinet instead of a knife drawer.
The Bottom Line
If you’re building an LLM agent, a web API, or any system that translates user input into database queries, you need this. Not because ORMs are bad, but because dynamic query generation from untrusted sources is the most dangerous thing you can do—and filtersql makes it safe by design.
Go check out the repo. It’s three files, zero dependencies, and one of the smartest security patterns I’ve seen in years. Your AI agent will thank you. Your database will thank you. And your sleep schedule will definitely thank you.
FAQ
Q: Why not just use parameterized queries with an ORM?
A: ORMs are designed for static queries written by humans. When an AI agent generates queries dynamically, you still need to parse and validate the structure. Filtersql replaces that parsing step with a safe JSON grammar, cutting out the risk of injection even before the ORM gets involved.
Q: Does filtersql work with any database?
A: Yes, it outputs standard parameterized SQL, so it works with PostgreSQL, MySQL, SQLite, and any database that supports bound parameters. The library itself is database-agnostic.
Q: Isn't it safer to just give the AI agent read-only access?
A: Read-only access doesn't prevent injection attacks—it still allows data exfiltration via malicious queries. Filtersql prevents injection altogether by ensuring the AI can only construct queries from a predefined grammar, regardless of permissions.