The onion model is the right mental frame. The nastiest failures are often not obviously bad SQL, they are valid queries that become dangerous only after the planner sees real cardinalities. Row limits and statement timeouts help, but a query can still thrash caches or hold locks before timeout hits. Is your pre execution cost check based on an EXPLAIN style plan with relation level budgets, or is it mostly AST heuristics plus database backstops? That boundary usually decides whether something feels safe enough for production data.

Isn't NL2SQL with Snowflake Qwen Model and NL2DAB from Microsoft MCP SQL Server already great enough with it's capability?

We have multiple production AI Agent for development, as long the "steering" is in set, it's powerful enough to work on and hallucinate less

I'm still not get the querybear said about "It will nuke database", when we give detailed plan before executed, it's already set isn't it?