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

Oracle's Jeff Smith explains how to let agents query enterprise databases safely through an MCP server, covering reports exposed as vetted tools, the risks of natural language to SQL, performance tuning on read-only standbys, schema annotations, and deep data security enforced at the database layer.

6 min read
Your AI Agent Wants Your Data. Here's How to Lock It Down - Jeff Smith, Oracle
source: https://www.youtube.com/watch?v=LnQce-eHm8k

Oracle AI Database as one surface for agents

Oracle positions its database as the place where agents can reach all enterprise data at once. Vector search is built into the database alongside relational tables, graph, and the many data types added over the last 30 years. Financial, HR, ERP, shipping, retail, government, and healthcare data can be vectorized and queried through a single SQL interface and one MCP server, instead of being replicated across eight or nine platforms. The underlying argument is that an agent is only as useful as its access to data, and the hard problem is providing that access without leaking PII.

Reports as tools instead of ad hoc SQL

The highest-return use case is the stream of business questions that flows from executives to whoever manages the data. Those questions are usually answered through BI publishers, data marts, and spreadsheets, and the bottleneck is people’s time rather than the number of questions. Generative AI removes that bottleneck, but natural language to SQL carries a risk that is easy to miss: a query can run cleanly and return plausible rows that answer a different question than the one asked. A cross join that makes no sense for the scenario will still produce output. Agents also brute-force the data dictionary to find what they need, which burns tokens and time.

The alternative is to expose the reports a team already trusts. Teams catalog their existing reports, describing each one’s purpose, sample questions, and parameters, while the SQL underneath stays fixed. The LLM can still pick the wrong report, but it cannot generate the wrong SQL, which removes one failure point. Registering hundreds of reports as individual tools would overwhelm the context window, so the server exposes two tools instead: list reports, which searches by key phrase, and execute reports, which runs the chosen one. Ad hoc SQL, stored procedures, and custom tools can each be enabled or disabled, so a team can limit the agent to vetted reports only.

There is also a mode aimed at teaching the agent. With the right OAuth 2 scope or role, the tool can show the agent the SQL behind a report, which reveals how the business’s data model is organized. An agent that has seen the query for monthly widget sales has a much better chance of writing a correct one on the first attempt.

Performance tuning against a read-only standby

The author does not want an LLM dropping or building indexes in production, and would prefer that agents never touch production at all. The model is advice first, with a human deciding what to act on. Oracle’s Data Guard provides a read-only standby where reporting and read queries can be offloaded, and a slow query in production will often reproduce there. The agent can investigate and try different tuning strategies in that safer environment.

Performance is an area where LLMs are strong, since Oracle’s documentation, PDFs, Stack Overflow answers, and blog posts are well represented in training data. Statistics matter a great deal. The cost-based optimizer builds execution plans from the actual profile of the data, such as the number of distinct values in a column, so fresh statistics lead to better plans. Rather than generating fifteen single-purpose tools, the design groups capabilities into three or four cross-category tools, each with options. A performance tuning tool, for example, offers six actions, including generating an AWR performance report and collecting statistics.

Security at the database layer

The core position is that security belongs in the database, not in the tools. If access rules live only in the tool layer, any engineer who points another client at the database bypasses them entirely. Authentication runs through single sign-on, such as Azure AD, rather than database accounts. The identity provider returns scopes and roles, and the database enforces policy based on them. Deep data security dynamically strips out rows the user is not permitted to see before results reach the agent. In the example, an HR manager can see everyone’s salary, while someone outside that organization gets results with that data removed.

Schema documentation for agents

Much of an organization’s data knowledge lives in people’s heads and in Confluence pages. A sales table may have an opaque name because an engineer thought it would be cool decades ago. New employees have always had to absorb this context, but agents make the cost visible and repeated, since each one rediscovers the schema through expensive queries. The answer is to put that context into the database itself, in plain English, which helps humans too.

The schema info tool returns a compressed JSON dictionary of tables, columns, and comments in verbose, slim, or medium modes, with keyword filtering. This replaces exploratory queries with a consistent, cheap response. A retrieve context tool pairs that metadata with vector search. A generate annotations tool can scan PDFs, slide decks, spreadsheets, and Word documents from a shared site, extract the text, and store it back in the database as annotations. The author’s example is a personal Strava dataset with inconsistent units, mixed time formats, and columns that do not mean what their names suggest. Once annotated, an agent asked what workout to do next week can reason from accurate data. Because the interface is MCP, it works with any model or agent that can call the server.

What’s coming

On the roadmap are MCP Apps, which would let the database interface render as a GUI directly inside the agent, expected later this year. Skills can be delivered through tools, and automated RAG pipelines are planned, where documents are loaded from the command line and the resulting vectors and snippets are returned to agents through an MCP tool. Because the protocol changes quickly, the goal is to keep pace with new features as they ship while keeping these integrations easy to use and safe by default.

Share post

Stay In The Loop! Subscribe to Our Newsletter.

Get updates straight to your inbox. No spam, just useful content.

Recommended for You

A Bank Built Its Own Coding Agent. It Took Off — Felipe Felisola Caso & Francesco Galletta, Monzo

A Bank Built Its Own Coding Agent. It Took Off — Felipe Felisola Caso & Francesco Galletta, Monzo

Felipe Felisola Caso and Francesco Galletta from Monzo explain how an internal Slack agent grew from a viral emoji trigger into a teammate authoring over 10% of merged PRs and running more than 1,800 tasks a day. They attribute its speed to existing platform capabilities, an MCP gateway, a sandboxed orchestration system suited to a regulated bank, and an agent designed as a composable building block for incidents, on-call data quality and non-engineer contributions.

What Is Loop Engineering? Building Better AI Agents

What Is Loop Engineering? Building Better AI Agents

Martin Keen explains loop engineering as the next step beyond prompt engineering: designing systems where AI agents act, observe, adjust, and repeat toward verifiable goals. The discussion covers goal design, triggers, context and persistent state, tools via MCP and APIs, verifier subagents, and why humans must remain in the loop to manage comprehension debt, intent debt, and cognitive surrender.