A new text-to-SQL entrant treats safety as three separate failures—not one regex

A new MIT-licensed project, Text-to-SQL Interface, is worth watching less for its model choice than for how it separates failure modes. The repository exposes an offline rule-based generator and an Anthropic provider, then puts generated SQL through input checks, SQL validation, schema-aware hallucination checks and a constrained executor before returning results. It was created on October 20 and remains an extremely early project: GitHub shows zero stars, zero forks and no established adoption signal. Source: project repository

The useful part is the separation of controls

The SQL layer parses statements with sqlglot rather than searching raw strings. Its implementation allows read-query roots, rejects multiple statements and write or administration nodes, blocks selected SQLite functions, excludes system tables, enforces an optional table allowlist and rewrites the outer query to cap its LIMIT. That makes the control inspectable and structurally harder to bypass with casing or comments than a keyword-only filter. Source: SQL guard implementation

The executor is a distinct backstop. It opens SQLite with mode=ro, enables PRAGMA query_only, installs a progress handler for timeouts and fetches no more than the configured row cap. In other words, a parser mistake does not automatically become permission to write. Source: executor implementation

The project also checks generated identifiers and query plans before execution. Its README says unknown tables or columns are errors, while ambiguous columns and suspicious joins reduce a confidence score; a failed query can be regenerated once with the findings before final rejection. The same documentation is explicit that the default offline generator covers only a narrow set of single-table patterns, while broader language coverage requires the Anthropic provider. Source: README

What is not proved yet

This is not evidence that the system is secure or accurate in production. The repository provides tests and CI, but no public text-to-SQL benchmark, adversarial red-team report or independent reproduction. Its current executor is SQLite-specific, so the read-only guarantees should not be generalized to PostgreSQL, MySQL or warehouses without separate implementations and tests. Source: repository tree

The practical takeaway is architectural: input intent, SQL structure, schema validity and database permissions are different controls. This entrant implements each visibly, which makes it more useful to inspect than projects that label a single blacklist “guardrails.” The next evidence to watch is a tagged release, third-party security testing and accuracy measured on a disclosed task set—not a larger feature list.