How to Give AI Agents Safer Database Access

Jeff Smith of Oracle discusses database access for AI agents in this 22-minute AI Engineer talk.

A successful query can still be wrong

Natural-language questions can produce SQL that runs and returns plausible data while answering the wrong question.
Business users may know what they want without knowing enough SQL or schema history to spot an incorrect join.
Smith recommends exposing vetted, parameterized reports: the agent chooses a report and inputs rather than writing its underlying query.
That removes one source of generated SQL errors, but the agent can still choose the wrong report or parameters.
A search tool and an execution tool can serve a large report catalog without exposing every report as a separate tool.

Oracle’s server can permit ad hoc SQL or restrict an agent to custom tools and reports; Smith describes both options.
For performance investigations, he suggests a read-only standby where available and keeping agents out of production when possible.
Read-only access is not sufficient: a user or agent may still be able to read sensitive data they should not see.
Enforce data permissions in the database itself, so a different client cannot simply bypass protections in one tool.
In his proposed setup, organizational single sign-on supplies identity and roles; database policies filter results before they reach the agent.

Annotate tables with business meanings, units and other context hidden by historical naming conventions.
Smith describes schema-information tools that return filtered metadata rather than having the agent repeatedly inspect tables and sample rows.
Existing documentation and report SQL can supply context, subject to the user’s authorization.
Oracle’s examples are a vendor presentation, not an independent test of accuracy, security or token savings. A standby still needs its own access controls and operational safeguards.

“I wrote a SQL query, data came back. Awesome, I got it right. No.” — Jeff Smith, 7:24