Engineering brief

Don't Let AI Agents Write Raw SQL: A Safer Pattern from Oracle

AI Engineer3 min read · saves 19 min

At a glance

The brief is enough

Relevance
Practical value
Radar
Time horizon
Now
Warnings
  • High hype
  • Vendor pitch

Oracle’s Jeff Smith argues that natural language-to-SQL is too risky for production. His alternative: let agents pick from pre-authorized reports, not generate queries.

Natural language SQL is dangerous in production. This talk offers a safer pattern.

Watch if you are evaluating how to give AI agents safe access to production databases.

Summary

The core argument. Jeff Smith from Oracle argues that the biggest risk with AI agents interacting with enterprise databases is not technical capability but data safety. He positions Oracle's AI database as a platform that natively supports vectors, graphs, and relational data within a single SQL interface, eliminating the need to replicate data across multiple stores for RAG pipelines.

The dangerous default. Smith warns that natural language to SQL, while exciting, is fundamentally unreliable and risky for production use. He points out that LLMs frequently generate queries that return plausible-looking but incorrect results, and that teams often lack the governance to catch these errors before they affect decisions. The financial and reputational cost of a wrong query or leaked PII is too high for most organizations.

A safer alternative. Instead of letting agents generate arbitrary SQL, Smith advocates for a report-based approach: pre-authorize parameterized reports that are hard-coded by experts. The agent selects the right report from a catalog, not the SQL to execute. Oracle's MCP server supports this with two tools: list reports and execute reports, keeping the LLM from generating queries directly.

Security at the database layer. Smith emphasizes that security must live in the database, not just in the tooling. Oracle pipes user identity through single sign-on (Azure AD) and applies row-level security dynamically based on roles. This means a query returns only the data the user is allowed to see, even if the agent generates the same SQL for two different people. This is the most important safeguard for production deployments.

Realistic use cases. Beyond reporting, Smith shows how agents can assist with performance tuning: diagnosing slow queries on a read-only standby instance, collecting optimizer statistics, and generating reports, but never making changes directly. He also describes schema annotation tools that document cryptic table names for both humans and agents, reducing the time spent reverse-engineering the data model.

The hype filter. This is largely a vendor pitch, albeit a pragmatic one. The report-based approach is a sensible governance mechanism, but the claim that Oracle's database is uniquely capable is unsubstantiated by benchmarks or independent evidence. The talk is most useful for the security architecture and the pattern of constrained agent actions, not the Oracle-specific features.

My take

I agree with the core pattern: constrain agents to pre-authorized actions rather than letting them generate queries. That's a sensible governance boundary that any team can implement with any database, not just Oracle. What I push back on is the implication that this is novel or Oracle-exclusive. It's basic security engineering: least privilege, role-based access, and careful auditing. The talk is useful for the pattern, not the product. Teams should adopt the principle of constrained agent tool design and test it with their own stack before buying into a vendor's story.

What to do with this

  1. Audit which existing reports or dashboards could be exposed as agent tools instead of letting agents generate SQL.
  2. Set up a test environment with a read-only replica and define a minimum set of agent permissions before any production deployment.
  3. Ask your security team to review whether current database access controls can enforce row-level security based on the calling user, not just the agent identity.

Watch the video

This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.

Related breakdowns

Get TL;DW

Too Long; Didn't Watch.

A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.

Free. Weekly. No hype.

Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.