Your AI Agent Wants Your Data. Here's How to Lock It Down - Jeff Smith, Oracle

In 25 years of building database tools at Oracle, Jeff Smith has learned that however good the tool gets, someone still wants an Excel spreadsheet. An agent might change who writes the query and assembles the pivot table. An executive will still use the numbers in a meeting, with little opportunity to spot a mistake in how they were calculated.

Oracle’s AI Database puts more of that work within reach of a single SQL interface. It can store vectors alongside the relational data they describe, so a retrieval-augmented generation pipeline can search information where the business already keeps it. The same database supports graph workloads, including graph-based retrieval. An agent can reach these capabilities through one Model Context Protocol (MCP) server. That leaves a design question for the team connecting it. How much should the agent be able to figure out, read, and execute for itself?

Database administrators and DevOps engineers are often the first to try an MCP server because they have permission to connect it. Smith sees a larger audience among the people fielding questions about regional performance, monthly widget sales, or the discount that might persuade shoppers to finish checking out. Those analysts know the business. They already work through data marts and BI reports to deliver answers. What they run short of is time for the next question.

Natural language to SQL removes some of that labor, but it also removes a chance to inspect the calculation. An inappropriate cross join can produce rows and a plausible sales total. The analyst who asked the question may have no reason to suspect that the join multiplied the underlying records. Even a correct answer can be expensive if the model has to search the database dictionary repeatedly to work out where sales are recorded.

Smith starts with the reports the team has accumulated on a network drive or in SharePoint. Someone has already worked out how the business counts a widget sale. The team can expose that query as a parameterized report, describe what it measures, document each input, and include sample questions that should lead an agent to it. The agent can still choose the wrong report. Once it chooses, the SQL implementing the calculation is fixed.

Giving each report its own MCP tool would put hundreds of descriptions into the agent’s context before it answered a question. In Smith’s example, a catalog of 500 reports needs only two operations. The agent calls List Reports with a key phrase, inspects the matching reports, then calls Execute Reports with its selection and inputs. It can format the returned data for the person who asked.

Teams can disable ad hoc SQL and stored procedure execution and limit the server to approved reports and custom tools. Where open-ended analysis is appropriate, the same catalog has another use. With the requisite scope or role in an OAuth 2 session, the agent can inspect the SQL behind a report. A monthly sales query then serves as a worked example of the organization’s data model, improving the agent’s chances of writing a related query correctly on its first attempt.

For a slow production query, Smith wants the model’s advice and reserves changes such as creating or dropping an index for a human. Oracle Data Guard can provide a read-only standby that serves reports and queries. If the slowdown reproduces there, an agent can investigate it without connecting to production. Smith describes reproduction as a good possibility, so the diagnosis still depends on what happens on the standby.

Smith describes a custom tuning tool with six permitted actions. One produces an AWR performance report. Another collects statistics that describe the data, such as the number of distinct values in a column. Oracle’s cost-based optimizer uses those statistics to choose an execution plan. Fresh statistics give it a better chance of choosing one that runs efficiently. Smith favors three or four tools organized by job, each with a small menu of actions, over exposing 15 single-purpose tools. He describes the tuning workflow without presenting a measured speedup.

Read-only access settles whether the agent can modify business records. It leaves open whether the agent can read someone’s salary. Smith puts that restriction in the database itself, where it also applies to an engineer who connects a different client.

A new hire might learn from a colleague that sales live in a table called XHR_123 because of a naming decision made 30 years ago. Left to discover that alone, an agent can enumerate tables, fetch columns and comments, and sample five rows from each table to see what the values resemble. Unless agents share memory across the team, the next person’s agent may pay for the same search all over again.

Oracle’s schema information tool returns a compressed dictionary of attributes in JSON. The agent can request slim, medium, or verbose output and filter by keyword. Teams can add the business meaning missing from the dictionary. The Generate Annotations tool can extract and organize text from SharePoint materials such as PDFs, slide decks, spreadsheets, and Word documents and store it in the database. Agents can retrieve that context through a tool or use vector search.

Smith uses his own Strava workout history as an example. He imports runs and rides through an API. The schema is reasonably well described, yet units and time conventions vary, and some columns contain something different from what their names suggest. Annotations explain those details before an agent tries to use past workouts to suggest next week’s training. The explanations are in plain English, readable by people and available to different models through the same MCP tools.

Two colleagues can ask the same agent the same question and be entitled to different answers. Oracle routes the caller through the organization’s single sign-on system, such as Microsoft Entra ID. The authenticated session supplies scopes and roles that the database can use to determine what that person may see, whether the request came through Claude, Codex, Gemini, or a homegrown LangChain application.

In Smith’s example, an HR manager may see everyone’s salary, while a colleague outside HR lacks that access. When the generated SQL runs, the database dynamically removes unauthorized rows before the result reaches the agent. Oracle calls this deep data security. The model never has to decide which salary records to hide from its answer because the database has already applied the caller’s permissions.

Smith distinguishes what teams could use at the time of the talk from what Oracle was building. Skills could already be delivered through tools. An automated retrieval pipeline could ingest documents from the command line and use an MCP tool to return vectors and document snippets to agents. Oracle was also developing MCP apps that would put a graphical database interface directly inside the agent, which Smith expected later that year.