Skip to content
Security & Trust Talking point

Let database agents tune a read-only copy and keep them out of production

Oracle's Jeff Smith wants agents to investigate a read-only standby copy, so experiments stay off the live system.

W
WebPulse Newsroom
AI-assisted · 2 min read
Share on X LinkedIn
Let database agents tune a read-only copy and keep them out of production
In brief
  • Oracle's Jeff Smith said he would keep AI agents out of production databases if he can, and let them tune a read-only standby copy instead.
  • He added that read-only access is not enough, because an agent can still read data it should never see. He wants the database itself to enforce limits.

Oracle veteran Jeff Smith, a 25-year builder of the company's database tools, spoke on the AI Engineer show. He argued that AI agents should look into database performance on a read-only standby copy, not on the live system. His stated aim is to keep agents out of production wherever possible.

What was said

Smith described an Oracle feature called Data Guard. It keeps a standby copy of the database that can only be read. Teams can send reports and read-only queries there. He said a performance problem on the live system would probably show up on the copy too.

The agent can then probe that safer copy and try out different tuning ideas. Smith put his rule bluntly. He said: "I'm not going to let the LLM or the agent into production at all if I don't have to."

He also described a custom tool. It has six actions he is happy to let an agent run for him. One creates a performance report. Another collects statistics that profile the data. The database uses them to choose how to run a query. Fresher statistics make a fast plan more likely. He said agents are very good at finding and fixing performance problems.

Read-only access, he added, is not enough. He put it this way: "even if you can only read the data, you might be able to read the data you don't want them to see." He wants the database itself to enforce limits. A rule built into only one tool fails if an engineer points another tool at the database.

Why it matters

Our reading: Smith draws the line where a mistake starts to cost real money. A bad tuning idea tried on a copy wastes some time. The same idea on the live system could hurt every user. Smith named the outcome he fears: leaked personal data and testifying before Congress. That cost lands on the people whose data leaks, and on the company.

For managers who buy agent tools, the question is less how clever the agent is. It is where the agent can reach, and who enforces that limit. Smith's answer is the database, not each tool. A buyer could ask a vendor where it draws that line.

The other side

The excerpts do not say who applies the agent's advice to production, or how. That a human makes every live change is an inference. Smith did not say it in these passages.

The excerpts also do not say which database the six-action tool targets. Collecting statistics changes the database. That is a different kind of act from the read-only investigation Smith describes for the standby.

Smith said only that the problem would probably show up on the standby. A fault that appears only under live traffic could be missed. He keeps agents out of production only when he can avoid it. That concedes some work may still need access.

Finally, this is an Oracle employee describing Oracle's features. The excerpts give no evidence from teams that run this setup. They do not say what a standby copy costs to maintain.

Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.

The conversation this talking point comes from