Oracle MCP 与数据库安全：为 AI Agent 筑牢数据防线

I'm Jeff. I'm from Oracle. I'm almost

[snorts] the exact same age as Oracle.

Does anyone know what year Oracle was

founded?

Same year Star Wars came out.

Yeah.

Um and I've been working with database

tools um

for about 25 years.

And I learned a truth very early on that

no matter how good of a tool you build,

at the end of the day what people want

are Excel spreadsheets.

Is that still true?

Has the agent killed Excel yet?

Well, they published the reverse

engineer anything, right? And then they

immediately reverse engineered Excel.

So, maybe Excel's still a thing.

Um the biggest question we've got at our

booth and from random people on the

street that see my Oracle jacket, other

than can I have your jacket, um is like

what is the Oracle AI database? So, who

in here has worked with or studied or

seen an Oracle database before?

Who in here is currently using Oracle?

Cool. Thank you. Um

so, what's an Oracle

AI database? Well, the only real way to

answer this question today is to ask

Claude.

Um

my agent's very well trained and

behaved. So, it actually had a pretty

good answer. The nutshell is

the database is now able to participate

in all of your rag pipelines because we

natively support vectors inside the

database.

So, if you've got financial data, HR

data, ERP, shipping,

um retail,

government, healthcare, whatever, if you

want to

look for information in that data

warehouse, that data lake, that data

sewer, that beautifully curated

database.

We can vectorize your information

alongside the data inside the database,

and we give you a single

SQL interface across all of that. So,

you don't have to replicate data across

eight or nine different platforms just

for your

Did you see that? That was like

Spider-Man.

Um

So, that means one MCP server

um into the database, and I'm here to

talk about MCP.

So, um

just see Oh, missed it that time.

It's not just vector that we've added to

the database. So, in addition to your

relational tables and columns, thank you

so much. Would you like a complimentary

pair of socks?

Yeah. [laughter]

Feel like you should have won a prize

for that.

Um

Yes, thank you.

Um

For 30 years, we've been adding um

data types and data workloads to the

database. So, we support all of these

things. Um also, graph. So, if you're a

fan of graph rag,

um

we can do that as well inside the single

instance of Oracle.

So,

people like to dig on Oracle cuz we're

old, that doesn't mean we've stopped

innovating. I mean, we we're inventing,

building, publishing new stuff

uh every month. We have to because

people are giving us lots of money, they

expect value in return for that.

talk about today

MCP, we're going to cover some uh

real-life use cases cuz that's the

biggest question I get is like

agents, LLMs, MCP great, who cares about

databases? Like, what what's the point

here? It And for me, it's very obvious.

I mean, like all of your data,

information, knowledge is inside a

database, and the agents thrive on on

data. So, how can we get that

information to them safely

without bringing the company down

because we've leaked PII or done

something horrible and end up in front

of Congress testifying about it.

I want to talk about uh the advancements

that we're pushing. You know, MCP is

brand new protocol, but they add stuff

almost every 3 months. So,

Oracle is there having these

conversations with the board and we're

trying to pick up the new features as

they come out.

And we don't have time for Q&A today,

but I do

I did bring some swag. I think most of

it's gone. If you want a bag or socks,

oh, we have some DB stuffies in the

back. We can

throw those at you.

Um I'll share some roadmap stuff as

well.

So, this is an hour talk and I was told

I have 20 minutes and then not really

just 18. Let's see how fast we can go

cuz I've wasted 2 minutes on the podium.

All right.

So, the three things I want you to be

able to walk away with, what we've

built, um the problems with natural

language to SQL, and some things that

we're trying to make that more

trustworthy,

and then anything I can share with you

folks that might help with token

optimization.

I think this is the last

use case that businesses end up

undertaking, but I also think it is the

biggest return for your buck. Um

generally the people managing the

infrastructure around the database are

the ones that get to hook up the new

technology. So,

when I say, "Hey, do you want to try an

MCP server?"

It's usually a database administrator, a

network administrator, a sysadmin, a

DevOps engineer that going to have the

ability to do that in the first place.

So, they'll use these tools to make

their lives easier. But if you look in a

company,

there are way more of these types of

people, the people that

get the questions from the SVP, the EVP,

God forbid the CXO saying,

"How many widgets did we sell last

month? How are we performing in this

region?

Um what discount rate should we run to

maximize um

people closing out their carts? All all

that fun stuff that I pretend to

understand." And so, what generally what

happens, they go into their BI

Publisher, they go into their data

marts, they they start building their

spreadsheets, they they pop out the

answer, and that ends up in a

in a meeting somewhere, and someone

makes very important decisions based on

the pivot tables and Excel spreadsheets

that have been compiled.

And these questions are

endless. Like

it's not that people run out of

questions [clears throat] to ask. They

don't have enough time and people to

answer those questions.

Like every second there's like, "Oh,

there's What if we try this? What if we

try that?" So, the beauty of

generative AI is like it's a force

multiplier, right? So, we had now have

the time and the resources to ask these

endless questions.

The problem is the data's in the

database,

and the people putting together these

spreadsheets,

[snorts]

they're not necessarily SQL

experts, data model architects. They

understand the business,

but they wouldn't recognize that a cross

join doesn't make sense for this

scenario.

So,

natural language to SQL is amazing,

but I think it's dangerous. Have you

ever heard the phrase, "If it compiles,

ship it?"

Engineers laugh about this.

We pretend to laugh along. Um

I wrote a SQL query, data came back.

Awesome, I got it right. No.

You didn't actually ask what you thought

you asked. The LLMs are going to

frequently run queries that look like

they're returning the right data, but

they're not. And there are various

reasons why the LLMs, although they're

getting better and better at this, are

still going to fall short. Like I would

not trust

Codex or Claude or Gemini or any of

these two decide

what business branch that we're going to

invest in XYZ just based on a prompt and

a and a thing that pops back.

It's also expensive to ask them to do

this stuff, too, cuz they're going to

brute force

your dictionary your your database

looking for the right data to answer

these questions. So, not only is going

to be unreliable and the people using

this these tools don't necessarily

understand what the the agents and MCPs

are doing on our behalf, but it's going

to take a lot of tokens and time to get

that data. So, one of the things we've

done at Oracle is said, "Hey,

as a business, as a team, as a group,

you've got a SharePoint, you've got a

network drive, you've got something

where there's

folders and folders and folders of

reports that you've compiled over the

years.

And these are the things that you look

at when people ask these questions. So,

why not find a way

to pipeline them into the database

and/or MCP server and present those

almost as like tools or APIs that the

agent can call. So, instead of the agent

tasking an LLM to generate a query, you

say, "Hey, these are the reports

available to you. Which of these would

you like to look at?"

So, that's what we've done at Oracle.

We allow you to take as many of these as

you want. Now, you do have to put some

time into this.

You'll need to describe the reports and

I like to include like, "Hey, here's

sample questions." You know, the agent

can say, "Hey, if you got a question

about this, this is a good report to

run." I describe what the report means.

I describe all the inputs, so of course

they're parameterized.

But, the code underneath the report is

more or less hard-coded.

So, the LLM might screw up by picking

the wrong report, but the LLM's not

going to screw up by generating the

wrong SQL.

So, it's just one less

plus place it can mess up.

Now, in terms of MCP tools,

I present

I present a tool called list reports and

execute reports.

So, I could have 500 reports, that's not

500 tools.

That would That would blow out context

and then agent would be like, "This is

This is too much. This isn't useful."

So, when I ask a question, it can say,

"Using this key phrase, give me any

report that looks like this." I'll get a

report list back and then I can execute

one of those reports to get the data

back.

This is an option above

natural language to SQL. So, our MCP

servers definitely support taking

arbitrary ad-hoc SQL stored procedure

code and executing it on the fly against

the database, but they also support

turning that off and limiting you to

custom tools and reports.

And there's another mode

for the context engineers out there.

These reports represent like

the blueprint for how the the business

works, for how the data model works. So,

if you have the proper scope or role in

your OAuth 2 authenticated session, the

tool will also offer to show the agent

the SQL behind the report.

So, it can learn how your data is

organized in the system and then it's

going to have a much better chance at

one-shotting the right query when it

goes to generate it. So, you're

basically say, "Here's some markdown

explaining how we find out the number of

widgets we sold last month."

And of course, here comes the results

back and our

agent nicely formats that.

Who in here started playing with MCP

apps?

Yeah. So, that was I think you're

introduced in the spec in July. That's

something I'm going to talk about

later on, like 5 minutes based on this

little clock.

Um

DevOps engineers, support folks,

our platform is very well known. It's

been around for a long time. The docs,

the PDFs, the GitHub projects, the Stack

Overflow questions, my blog posts,

they're all out there. The LLM's been

trained on it. They know what to look at

if a query is slow. But, I don't trust

an LLM to drop an index, to

build an index even, to do anything in

the database for me. I want it to give

me advice and then I'll action

that advice.

And then if anything, I'm not going to

let the LLM or the agent into production

at all if I don't have to.

Does that sound crazy?

So, how do I use an agent or LLM to get

help with a production system that's

running slow?

Everyone here has a test environment

that mirrors production, right?

No?

Um

we have a technology at Oracle called

Data Guard that allows you to have a

read-only standby instance where you can

offload like reports and read-only

queries to. So, there's a good chance

your performance issue would replicate

over there. You can have your agent go

attack, not attack, that not the right

word. That's the right word actually

sometimes. You can have your agent go

interrogate that safer environment to

investigate and try out different

performance

um

tricks.

So, I am looking to give the LLM's

read-only access, but that's not enough.

I also need to lock down what they can

do once they're in there cuz even if you

can only read the data, you might be

able to read the data you don't want

them to see.

Um

we can do that a couple different ways,

but for me, the best place to always

implement security for the database is

where?

At the database.

If you build security only into your

tools, what happens when

a zealous engineer decides to go pick up

another tool and point it at your

database, they just go straight in,

right? But if you put security at the

database layer,

more times than not you're going to be

okay.

The agents and LLMs are really, really

good at finding and fixing performance

issues.

This is probably the easiest demo for me

to do. I don't have time to do demo, but

I've written a custom tool.

This tool has six

different actions that I'm a cool with

it to do on my behalf, and one of those

is to collect statistics

that basically profiles the data.

We have something called a cost-based

optimizer. So, when you ask queries, the

plans that get generated, they don't get

generated based on rules of thumb. We

look at the profile of the data, like

how many unique values are in this

column.

Yada yada yada. The fresher and the

better the statistics are, the better

chance it's going to generate a good

execution plan and have a good

performance profile runtime.

So, I'm not generating 15 tools that are

single-use tools. I'll generate three or

four tools that cross categories, and

each of those tools have options.

So, my agent can see, oh, here's a

performance tuning tool. It can do six

things. One of those is like generating

uh

a performance profile report. We have a

feature called um AWR. I'll let it

generate a report. One of the other

things I'll let it do is is generate

statistics.

case, schema exploration and

documentation.

Man, I'm running out of time.

So,

natural language to SQL is really

awesome. It's where most

of the excitement around AI and

databases lie,

which makes sense cuz SQL's the

most popular way to get stuff out of a

database. We need that data,

but it's a nightmare for a lot of these

systems.

Has anyone started a job in the last 6

months?

Is there like a place in the break room

where they put on the corner like a a

diagram where all of the hard stuff is

defined, all of the code words are

listed, all of the

all of the inside jokes are documented,

where the data model is explained. Hey,

our sales aren't in a sales table,

they're in a table called XHR_123

because an engineer 30 years ago thought

that would be cool.

Yeah, it's a big Confluence page.

We have tools now that will let you

consume those Confluence pages and

generate context and document uh

schema

metadata over top of the metadata that's

already in your database.

So, it's another context engineering

exercise. We want to be able to deliver

to the LLM the information about the

database environment you're talking to

instead of relying on it to generate

queries to reverse engineer hack your

database to look for data.

It will find the data if you ask it,

it'll just take a long time, and it'll

look for it

multiple times, and unless you have

shared team enterprise memory across

everyone's agents and LLMs, it's just a

it's just just a huge waste. So, what

we're like with

for some reason it wasn't a big problem

to let new employees suffer when they

joined an org.

Like it wasn't it wasn't a big enough

problem to fix this issue 30 years ago,

but now that AI is a thing, we can't let

the poor bots suffer. So, we got to get

them the information they need to

to make it easier to use our databases.

The The nice thing about this feature is

it's all in plain English, it's in the

database, it it's going to help the

humans, too.

So, when you go look at our tools, we

have something called schema

information. So, I'll say, "Hey,

Codex, Claude, whatever, I've got a new

um environment. I need you to go look

into it and see how laid out, find this,

and let's go summarize the information.

It'll see that it has a schema info

tool, and it'll start using that, and

that returns back a compressed

dictionary

a set of attributes in JSON versus it

running queries. Hey, show me all the

tables, show me all the columns, show me

all of the comments. Let's go read five

rows out of each table to see if the

data has what we looks like. You know,

we just kind of built that into the

tool,

optimized it, and it always returns the

same data, and it has multiple modes.

You can go verbose, slim, medium, just

like my pants, and uh

it's got filtering. So, you can give it

keywords, and it just looks for specific

things in the data.

[snorts]

And then I can pull that back out

with another tool called retrieve

context, where I can use that

information to

do AI vector search, but I have another

new tool called generate annotations.

So, I can point it to that SharePoint

site that you have, scan in your PDFs,

your PowerPoints, your Excel, your Word

docs,

um and store those in um or pull the

text out, organize it, and and put it

back into the database.

This is also it's easier to one-shot SQL

queries when you have natural language

to SQL exercises.

This is what the data looks like in the

database after I've properly annotated a

table.

So, anytime I do a run or a bike ride or

whatever, it goes into my Strava

account. I'm a nerd, so I have an API on

that data, and I store it in my

database. And their schema is fairly

well described, but

it jumps between like units of measure

and time, and some of the columns don't

have what you think they do. So, I just

have that all annotated, and so when I

start asking questions about, "Hey, what

kind of workout should I do next week?"

and it looks at my personal workout

history, it it gets to that much easier

with this with this info.

And the nice thing about this with MCP

is AI and LLM agnostic. It's going to

work for everything as long as the MCP

server and the tools are there.

important thing I talk about, security.

So, I got 40 seconds. We'll just end on

this.

Um

we need to know who is looking at the

information in the database before we

return any data back to them.

The information I'm allowed to see is

going to be much different than what the

data my colleague Tara is going to be

able to see. And when I'm in the

database using Claude or Codex or Gemini

or my own homegrown LangChain framework,

we don't use database authentication to

let the agent go in and do stuff. We

pipe you through your

organization single sign-on. So, like

Azure AD, which is going to return a

list of scopes, which is going to return

a list of roles that describe your role

in the organization, and the database

can be coded to say, "Oh, Jeff is an HR

manager. He's allowed to see everyone's

salary."

But no one else outside that org can.

So, when we the natural language

questions get generated to SQL, when

that SQL runs against the database, the

database dynamically strips data from

the result set before it comes back down

to the agent. We call that deep data

security.

I'm out of time.

I covered the big stuff.

We thought a lot about security at

Oracle. We want this stuff to be easy,

but we want it to be safe.

We are building MCP apps,

so you can have the database interface

GUI directly in your agent. That's

coming later this year.

[snorts]

We have skills.

The skills can be delivered via tools.

We support automated rag pipelines. You

can use a command line to suck documents

in and then an MCP tool

pipe the the vectors and the

the snippets of the the documents back

to your agents.

And when you want to learn more about

any of this stuff, we have the easiest

URL oracle.com/mcp.

I'm leaving to get on a plane to fly

back to Raleigh, North Carolina, but if

you find me on LinkedIn, I'm that Jeff

Smith and my colleagues are down at the

Oracle booth and they have more swags.

If you missed out on the plushy, we have

more. Thanks, everyone.

[applause and music]