Jeff Smith on Safer Database Access for AI Agents

I’m Jeff Smith from Oracle, and I’ve spent about 25 years working on database tools. One thing I learned early is that, however good a tool you build, people still want their answers in Excel. Even in the age of agents, the business questions behind those spreadsheets have not gone away.

People keep asking what the Oracle AI Database is. My short answer is that the database can participate in retrieval-augmented generation pipelines because it supports vectors natively. You can work with vectorized information alongside business data and query it through SQL, rather than replicating everything into a separate system for every workload.

Vectors are not the only workload we support. Alongside relational tables and columns, Oracle has added other data types and graph capabilities, including support for graph-based RAG. The company is old, but we continue to build and release new features.

The reason I care about MCP is straightforward: an organization’s data and knowledge are in databases, and agents need context. The difficult part is getting information to them safely without leaking personally identifiable information or otherwise harming the business. I’ll focus on use cases, the risks of natural language to SQL, and ways to reduce token use.

The first use case is self-service data access. Database administrators and DevOps engineers are often the first to connect a new MCP server, because they have access to the infrastructure. But a much larger group of business users must answer questions about sales, regional performance or discounts for their leaders.

Today those people search data marts and BI reports, build spreadsheets and pivot tables, and bring the results to meetings where important decisions are made. The questions do not run out; the scarce resources are the time and people needed to answer them. Generative AI could help people investigate more of those questions.

There is a catch: the people who understand the business are not necessarily SQL experts. They may not recognize that an agent has chosen an inappropriate cross join. A query that runs and returns rows is not necessarily answering the question the user intended to ask.

That is why I think natural-language-to-SQL is powerful and dangerous. Models can produce plausible but wrong queries, and I would not let a returned result alone decide where the business should invest. The agent may also spend considerable time and tokens probing the data dictionary to find the right tables.

Most organizations already have folders of reports they use repeatedly. My suggestion is to make those vetted reports available through the database or an MCP server as tools the agent can call. Instead of generating SQL from scratch, the agent can discover the relevant report and supply its inputs.

This takes preparation. Describe each report, what it means, the inputs it accepts and examples of questions it can answer. The inputs are parameterized while the underlying report query is largely fixed. The model can still choose the wrong report, but it has one fewer opportunity to invent the wrong SQL.

I do not need to expose 500 reports as 500 separate tools. I can offer a list-reports tool and an execute-reports tool. The agent searches the catalog using a key phrase, receives matching reports and runs the selected one. Keeping the tool surface compact also avoids crowding the context with hundreds of definitions.

Oracle’s MCP servers can also execute arbitrary ad hoc SQL or stored procedures, but they support disabling that capability and limiting access to custom tools and reports. Which mode to use is a security and governance decision; the existence of an execution tool does not mean every agent should receive it.

Reports can serve another purpose: they show how the business and its data model work. If an OAuth 2 session has the appropriate scope or role, a tool can expose the SQL behind a report. The agent can use that example as context when it needs to formulate a new query, rather than guessing the organization’s definitions.

The second use case is performance tuning. Database documentation and examples are widely available, so models can often suggest what to inspect when a query is slow. Even so, I do not trust an LLM to drop or create an index in production on its own. I want advice that a person can evaluate and act on.

Ideally I would keep the agent away from production altogether. A test environment may not mirror production, but Oracle Data Guard can provide a read-only standby that serves reports and queries. If the performance problem also appears there, the agent has a safer place to investigate possible improvements.

Read-only access is not enough by itself: an agent may still be able to read information it should not see. Enforce security at the database layer, not only in a particular client tool. Otherwise someone can point a different tool at the same database and bypass controls that existed only in the first one.

For a tuning example, I built a custom tool with six operations I am comfortable allowing. One collects statistics about the data. A cost-based optimizer uses information such as the number of distinct values in a column to choose an execution plan; fresher, better statistics can improve its chances of choosing a good plan.

Rather than expose a separate tool for every single action, I group related operations into a few tools with options. A performance tool might produce an Automatic Workload Repository report or collect statistics. The agent can help investigate, while the database administrator retains control over consequential changes.

The third use case is schema exploration and documentation. A new employee rarely finds a perfect map of internal terminology, table names and business rules. A sales figure might live in a surprisingly named table because of a decision made decades ago. Models face that same gap when asked to generate SQL.

We can use existing documentation, such as Confluence pages, to add natural-language annotations to schema metadata. This is context engineering: give the model information about the environment instead of making it repeatedly reverse-engineer the database. The annotations can help people as well as agents.

Our schema-information tool returns a compressed dictionary of attributes in JSON. It can provide different levels of detail and filter by keywords. That replaces a series of exploratory calls to list every table and column, retrieve comments and sample rows just to work out where the relevant data might be.

A retrieve-context tool can use that information for vector search. A generate-annotations tool can process documents such as PDFs, presentations, spreadsheets and Word files, extract and organize the text, and store annotations in the database. The aim is to provide more useful context for a later natural-language query.

I use my own Strava workout history as an example. I collect the data via an API and store it in the database, but some columns use different units or contain things their names do not make obvious. Annotating those details makes it easier for an agent to interpret my history when I ask about a future workout.

Finally, security starts with knowing who is asking. My colleague and I may be entitled to see different information. In the design I describe, the agent uses the organization’s single sign-on identity and the associated scopes and roles, so access can reflect the actual user rather than a shared, unrestricted identity.

For example, the database can permit an HR manager to see salary data while restricting others. When generated SQL runs, database policies filter the result before it reaches the agent; Oracle calls this deep data security. This depends on correctly configured identity, roles and database policies—it is not something to assume merely because an agent is connected.

I close with a brief product roadmap: Oracle is building MCP apps for database interfaces inside agents and offers skills and automated RAG pipelines. The specific capabilities and availability I describe are Oracle’s product plans; the broader lesson is to make database access useful while retaining explicit control over identity, privileges and execution.