What we learned about letting agents into a production database

Oracle is bringing its agent memory and Model Context Protocol work to AGNTCon + MCPCon Europe, including a workshop showing developers how to use Oracle AI Database as durable memory for AI agents, and how to let agents query enterprise data without generating their own SQL.

Someone in your business asks their agent what discount rate you should offer in APAC next quarter. It thinks for a moment and says 25%.

Would you be confident to ship that answer?

That question came up when we sat down with Jeff Smith, who leads much of our Model Context Protocol work at Oracle, to talk about what our customers are running into. We had expected a conversation about protocols and plumbing. It was mostly about trust.

Why does an agent need a database at all?

Start with the thing that makes agents hard to build. Language models are stateless. Ask one a question today and it answers as though it has never met you, because unless you send the entire history back with every request, it has no durable awareness of anything that came before.

Fine for a chat window. It falls apart the moment you want an agent that runs for weeks, remembers what it decided in March, and can explain why. Memory is what turns a stateless model into an application that survives contact with a real business.

Agents need somewhere to keep what they learn, and once that memory holds real company information it belongs where the rest of your data already lives, under the same access rules, backups and auditing. That makes it a database problem, and we have been working on those since 1979, when Oracle shipped the first commercially available SQL database.

It is why Oracle AI Agent Memory extends Oracle AI Database into a persistent memory core for agents: working memory for the task in hand, long-term factual memory, and procedural memory for how a job actually gets done. Our researchers published a paper on it in July, and teams across the company are building the connective tissue that lets agents reach it.

Which brings you back to the question we opened with. Once an agent can reach your data, how far do you trust what it does with it?

What actually goes wrong when an agent talks to a database?

The failure people brace for is the agent writing broken SQL. That is not the failure that hurts.

The one that hurts is syntactically perfect SQL returning a number that is confidently wrong. The agent goes through your schema, finds an employees table, a sales table, a partners table, works out how it thinks they relate, and comes back with an answer. The query runs clean. Nothing errors. The number is just wrong, because the agent decided “month” meant days since first purchase rather than a calendar month, and nobody catches it for a quarter.

A bar chart of execution accuracy on the BIRD text-to-SQL benchmark, as published on 21 August 2026. The best published model reaches 80.04 per cent and human performance sits at 92.96 per cent. — BIRD benchmark graphic comparing best published execution accuracy with human performance.

Ask again tomorrow and it may write a different query. So you end up engineering your prompts harder and harder to coax good SQL out of a model that has no idea which of your forty tables finance actually trusts. On the BIRD benchmark, as published on 21 August 2026, the best model on the leaderboard reaches 80.04% execution accuracy against 92.96% for humans. Respectable engineering, and worth rechecking before you quote it, because leaderboard positions move. Either way, not a number you want underneath a pricing decision.

What if the agent did not write the query at all?

This is the part we keep coming back to at Oracle. Your business already solved this, years ago.

Somewhere in your organisation, there are two dozen reports your analysts use to answer exactly these questions, and behind each is a query somebody wrote, argued about, checked and eventually trusted enough to put in front of the business.

So our managed service lets you publish those reports to the agent as governed MCP tools. Each one arrives with the same contract any other tool on the protocol gets: a name, a description the agent can reason about, typed inputs it has to fill, and access control deciding who may call it at all.

Three panels. The analyst's report is a query already argued about and trusted. It is published as a governed MCP tool with typed inputs, access control and fixed SQL underneath. The agent picks the report and fills in the inputs, and is never asked to write the query. — Governed SQL tool design: an agent selects a trusted analyst report and supplies typed inputs.

The agent sees something like a sales trends report with clearly typed inputs for quarter, region and business unit. It picks one and fills in the inputs. It does not write a line of SQL. The query underneath is fixed, so the same question follows the same trusted query path every time. If the number moves, it is because the data moved, not because the model phrased the question differently on a Tuesday. And the path it followed is one your analysts already stand behind.

The shift sounds small but is significant in practice. The agent no longer has to be clever enough to work out the right SQL. Only clever enough to pick the right report.

We should be straight about how new this is. Not many people work this way yet and we are still learning where it breaks. Natural language to SQL works perfectly well on our stack and plenty of teams will keep using it. But reusing work your analysts already trust, rather than asking a model to reinvent it live, is worth arguing about in public.

Who is the agent, and what is it allowed to see?

The other half of every customer conversation is about security, and the industry has not been subtle about why.

In May the United States National Security Agency published seventeen pages on Model Context Protocol security, finding that adoption has outpaced the safeguards. More than forty security vulnerabilities have been filed against implementations of the protocol this year. As Vipin Samar, our senior vice president for database security, put it, agents are increasingly acting as autonomous insiders.

We treat an agent as what it is: another application that proves who it is before it gets anything. It signs in through the corporate identity system your staff already use, and it inherits that person’s permissions rather than getting a set of its own.

Three panels. The agent signs in through the corporate identity system and holds no standing credential of its own. Its permissions are inherited from the person it acts for, not granted separately. Row, column and cell policy is declared once in SQL and enforced whether the request comes from a person or an agent. — AI agent access controls: corporate sign-in, inherited permissions, and SQL-enforced policy.

Underneath sits the database security we have been building for more than four decades. Oracle Deep Data Security extends the access controls our customers already rely on rather than replacing them, expressing them as policies you declare in SQL instead of code you maintain. It reaches individual rows, columns and cells, so two people asking an agent the same question see only what each is cleared to see. Salaries stay hidden from those who should not see them, whether the request comes from a person or an agent acting for them.

None of that makes prompt injection go away. It does not. What it decides is how much of your data is reachable when something does go wrong, which is the question your security team will actually ask.

Four ways to connect

There is no single Oracle connector for this, because there is no single way people run Oracle. One runs locally on a developer’s machine, which is how most people meet this first. One is built into Autonomous Database with nothing to install. One is a managed service in Oracle Cloud that also reaches Oracle databases running inside Amazon, Microsoft and Google’s clouds, at no extra charge. And where data stays in a customer’s own data centre, there is a version they run themselves.

Alongside those we publish an open repository of reference connectors for the wider Oracle estate, from MySQL to a toolkit that reads your database driver logs and tells you why last night got slow.

Come and talk to us in Amsterdam

Oracle is a Gold member of the Agentic AI Foundation, the Linux Foundation body that now hosts the Model Context Protocol, and we are sponsoring AGNTCon + MCPCon Europe at the RAI in Amsterdam on 17 and 18 September.

We’re also bringing a hands-on workshop. It walks through giving an agent durable memory with Oracle AI Database underneath and connecting the agent to that memory over the Model Context Protocol. If you are building AI applications and have not yet worked out where the database fits, that session is built for you.

We will be in the Solutions Showcase for the rest of the event. Come and tell us what you are building, and we will talk through how to put a database behind it. If you think letting agents call pre-approved reports is the wrong shape, tell us that too. We are early enough in this to still be changing our minds.

Learn more: oracle.com/mcp and github.com/oracle/mcp