WEBVTT NOTE Sentence-level transcript of https://www.youtube.com/watch?v=LnQce-eHm8k NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/LnQce-eHm8k.html. A cue ends where the next begins, or 2 s after its last word. s1 00:00:01.309 --> 00:00:03.309 [music] s2 00:00:12.520 --> 00:00:13.160 I'm Jeff. s3 00:00:13.160 --> 00:00:14.720 I'm from Oracle. s4 00:00:14.720 --> 00:00:15.065 I'm almost s5 00:00:15.065 --> 00:00:15.480 [snorts] s6 00:00:15.480 --> 00:00:17.200 the exact same age as Oracle. s7 00:00:17.200 --> 00:00:21.480 Does anyone know what year Oracle was founded? s8 00:00:22.120 --> 00:00:25.440 Same year Star Wars came out. s9 00:00:25.560 --> 00:00:26.920 Yeah. s10 00:00:26.920 --> 00:00:33.640 Um and I've been working with database tools um for about 25 years. s11 00:00:33.640 --> 00:00:41.520 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. s12 00:00:41.520 --> 00:00:43.920 Is that still true? s13 00:00:43.920 --> 00:00:47.200 Has the agent killed Excel yet? s14 00:00:48.120 --> 00:00:50.560 Well, they published the reverse engineer anything, right? s15 00:00:50.560 --> 00:00:52.560 And then they immediately reverse engineered Excel. s16 00:00:52.560 --> 00:00:55.800 So, maybe Excel's still a thing. s17 00:00:55.800 --> 00:01:06.640 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? s18 00:01:06.640 --> 00:01:12.720 So, who in here has worked with or studied or seen an Oracle database before? s19 00:01:12.720 --> 00:01:15.920 Who in here is currently using Oracle? s20 00:01:16.160 --> 00:01:16.480 Cool. s21 00:01:16.480 --> 00:01:17.400 Thank you. s22 00:01:17.400 --> 00:01:20.640 Um so, what's an Oracle AI database? s23 00:01:20.640 --> 00:01:25.800 Well, the only real way to answer this question today is to ask Claude. s24 00:01:25.800 --> 00:01:28.560 Um my agent's very well trained and behaved. s25 00:01:28.560 --> 00:01:31.160 So, it actually had a pretty good answer. s26 00:01:31.160 --> 00:01:41.600 The nutshell is the database is now able to participate in all of your rag pipelines because we natively support vectors inside the database. s27 00:01:41.600 --> 00:01:58.200 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 s28 00:01:58.200 --> 00:02:00.600 beautifully curated database. s29 00:02:00.600 --> 00:02:09.560 We can vectorize your information alongside the data inside the database, and we give you a single SQL interface across all of that. s30 00:02:09.560 --> 00:02:17.760 So, you don't have to replicate data across eight or nine different platforms just for your Did you see that? s31 00:02:17.760 --> 00:02:19.920 That was like Spider-Man. s32 00:02:19.920 --> 00:02:29.560 Um So, that means one MCP server um into the database, and I'm here to talk about MCP. s33 00:02:31.720 --> 00:02:37.200 So, um just see Oh, missed it that time. s34 00:02:37.320 --> 00:02:40.400 It's not just vector that we've added to the database. s35 00:02:40.400 --> 00:02:43.680 So, in addition to your relational tables and columns, thank you so much. s36 00:02:43.680 --> 00:02:47.360 Would you like a complimentary pair of socks? s37 00:02:47.560 --> 00:02:47.681 Yeah. s38 00:02:47.681 --> 00:02:49.160 [laughter] s39 00:02:49.160 --> 00:02:51.680 Feel like you should have won a prize for that. s40 00:02:51.680 --> 00:02:55.600 Um Yes, thank you. s41 00:02:55.920 --> 00:03:01.200 For 30 years, we've been adding um data types and data workloads to the database. s42 00:03:01.200 --> 00:03:03.280 So, we support all of these things. s43 00:03:03.280 --> 00:03:04.959 Um also, graph. s44 00:03:04.959 --> 00:03:11.880 So, if you're a fan of graph rag, um we can do that as well inside the single instance of Oracle. s45 00:03:11.880 --> 00:03:16.720 So, people like to dig on Oracle cuz we're old, that doesn't mean we've stopped innovating. s46 00:03:16.720 --> 00:03:21.560 I mean, we we're inventing, building, publishing new stuff uh every month. s47 00:03:21.560 --> 00:03:28.040 We have to because people are giving us lots of money, they expect value in return for that. s48 00:03:28.360 --> 00:03:28.720 All right. s49 00:03:28.720 --> 00:03:39.239 So, what I want to actually 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, s50 00:03:39.239 --> 00:03:41.560 MCP great, who cares about databases? s51 00:03:41.560 --> 00:03:42.680 Like, what what's the point here? s52 00:03:42.680 --> 00:03:44.239 It And for me, it's very obvious. s53 00:03:44.239 --> 00:03:50.480 I mean, like all of your data, information, knowledge is inside a database, and the agents thrive on on data. s54 00:03:50.480 --> 00:04:02.720 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. s55 00:04:02.720 --> 00:04:05.920 I want to talk about uh the advancements that we're pushing. s56 00:04:05.920 --> 00:04:09.800 You know, MCP is brand new protocol, but they add stuff almost every 3 months. s57 00:04:09.800 --> 00:04:18.440 So, Oracle is there having these conversations with the board and we're trying to pick up the new features as they come out. s58 00:04:18.440 --> 00:04:23.200 And we don't have time for Q&A today, but I do I did bring some swag. s59 00:04:23.200 --> 00:04:24.440 I think most of it's gone. s60 00:04:24.440 --> 00:04:28.720 If you want a bag or socks, oh, we have some DB stuffies in the back. s61 00:04:28.720 --> 00:04:31.840 We can throw those at you. s62 00:04:31.840 --> 00:04:35.640 Um I'll share some roadmap stuff as well. s63 00:04:36.640 --> 00:04:41.000 So, this is an hour talk and I was told I have 20 minutes and then not really just 18. s64 00:04:41.000 --> 00:04:45.720 Let's see how fast we can go cuz I've wasted 2 minutes on the podium. s65 00:04:45.720 --> 00:04:47.120 All right. s66 00:04:47.120 --> 00:04:59.960 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, s67 00:04:59.960 --> 00:05:06.080 and then anything I can share with you folks that might help with token optimization. s68 00:05:07.320 --> 00:05:09.440 All right, use cases. s69 00:05:09.440 --> 00:05:18.960 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. s70 00:05:18.960 --> 00:05:25.680 Um generally the people managing the infrastructure around the database are the ones that get to hook up the new technology. s71 00:05:25.680 --> 00:05:29.760 So, when I say, "Hey, do you want to try an MCP server?" s72 00:05:29.760 --> 00:05:37.880 It's usually a database administrator, a network administrator, a sysadmin, a DevOps engineer that's going to have the ability to do that in the first place. s73 00:05:37.880 --> 00:05:41.760 So, they'll use these tools to make their lives easier. s74 00:05:41.760 --> 00:05:52.120 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 s75 00:05:52.120 --> 00:05:56.200 saying, "How many widgets did we sell last month? s76 00:05:56.200 --> 00:05:58.720 How are we performing in this region? s77 00:05:58.720 --> 00:06:04.400 Um what discount rate should we run to maximize um people closing out their carts? s78 00:06:04.400 --> 00:06:07.680 All all that fun stuff that I pretend to understand." s79 00:06:07.680 --> 00:06:18.720 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 s80 00:06:18.720 --> 00:06:26.320 in a meeting somewhere, and someone makes very important decisions based on the pivot tables and Excel spreadsheets that have been compiled. s81 00:06:26.320 --> 00:06:30.360 And these questions are endless. s82 00:06:30.360 --> 00:06:33.840 Like it's not that people run out of questions [clears throat] to ask. s83 00:06:33.840 --> 00:06:37.360 They don't have enough time and people to answer those questions. s84 00:06:37.360 --> 00:06:39.760 Like every second there's like, "Oh, there's What if we try this? s85 00:06:39.760 --> 00:06:41.040 What if we try that?" s86 00:06:41.040 --> 00:06:45.520 So, the beauty of generative AI is like it's a force multiplier, right? s87 00:06:45.520 --> 00:06:51.240 So, we had now have the time and the resources to ask these endless questions. s88 00:06:51.240 --> 00:06:57.239 The problem is the data's in the database, and the people putting together these spreadsheets, s89 00:06:57.239 --> 00:06:58.000 [snorts] s90 00:06:58.000 --> 00:07:03.000 they're not necessarily SQL experts, data model architects. s91 00:07:03.000 --> 00:07:09.400 They understand the business, but they wouldn't recognize that a cross join doesn't make sense for this scenario. s92 00:07:09.400 --> 00:07:15.680 So, natural language to SQL is amazing, but I think it's dangerous. s93 00:07:15.680 --> 00:07:19.640 Have you ever heard the phrase, "If it compiles, ship it?" s94 00:07:19.640 --> 00:07:21.520 Engineers laugh about this. s95 00:07:21.520 --> 00:07:23.120 We pretend to laugh along. s96 00:07:23.120 --> 00:07:26.080 Um I wrote a SQL query, data came back. s97 00:07:26.080 --> 00:07:27.720 Awesome, I got it right. s98 00:07:27.720 --> 00:07:30.840 No. You didn't actually ask what you thought you asked. s99 00:07:30.840 --> 00:07:35.680 The LLMs are going to frequently run queries that look like they're returning the right data, but they're not. s100 00:07:35.680 --> 00:07:40.919 And there are various reasons why the LLMs, although they're getting better and better at this, are still going to fall short. s101 00:07:40.919 --> 00:07:55.480 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. s102 00:07:56.560 --> 00:08:04.960 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. s103 00:08:04.960 --> 00:08:15.160 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 s104 00:08:15.160 --> 00:08:16.360 to get that data. s105 00:08:16.360 --> 00:08:27.040 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 s106 00:08:27.040 --> 00:08:32.440 folders and folders and folders of reports that you've compiled over the years. s107 00:08:32.440 --> 00:08:36.400 And these are the things that you look at when people ask these questions. s108 00:08:36.400 --> 00:08:48.880 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. s109 00:08:48.880 --> 00:08:55.800 So, instead of the agent tasking an LLM to generate a query, you say, "Hey, these are the reports available to you. s110 00:08:55.800 --> 00:08:58.160 Which of these would you like to look at?" s111 00:08:58.160 --> 00:09:00.280 So, that's what we've done at Oracle. s112 00:09:00.280 --> 00:09:03.800 We allow you to take as many of these as you want. s113 00:09:03.800 --> 00:09:06.280 Now, you do have to put some time into this. s114 00:09:06.280 --> 00:09:12.000 You'll need to describe the reports and I like to include like, "Hey, here's sample questions." s115 00:09:12.000 --> 00:09:16.080 You know, the agent can say, "Hey, if you got a question about this, this is a good report to run." s116 00:09:16.080 --> 00:09:17.640 I describe what the report means. s117 00:09:17.640 --> 00:09:21.080 I describe all the inputs, so of course they're parameterized. s118 00:09:21.080 --> 00:09:25.839 But, the code underneath the report is more or less hard-coded. s119 00:09:25.839 --> 00:09:32.760 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. s120 00:09:32.760 --> 00:09:37.040 So, it's just one less plus place it can mess up. s121 00:09:37.040 --> 00:09:47.760 Now, in terms of MCP tools, I present I present a tool called list reports and execute reports. s122 00:09:47.760 --> 00:09:51.880 So, I could have 500 reports, that's not 500 tools. s123 00:09:51.880 --> 00:09:56.600 That would That would blow out context and then agent would be like, "This is This is too much. s124 00:09:56.600 --> 00:09:58.040 This isn't useful." s125 00:09:58.040 --> 00:10:03.520 So, when I ask a question, it can say, "Using this key phrase, give me any report that looks like this." s126 00:10:03.520 --> 00:10:08.080 I'll get a report list back and then I can execute one of those reports to get the data back. s127 00:10:08.080 --> 00:10:12.040 This is an option above natural language to SQL. s128 00:10:12.040 --> 00:10:26.480 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 s129 00:10:26.480 --> 00:10:28.160 and reports. s130 00:10:28.160 --> 00:10:32.280 And there's another mode for the context engineers out there. s131 00:10:32.280 --> 00:10:37.960 These reports represent like the blueprint for how the the business works, for how the data model works. s132 00:10:37.960 --> 00:10:49.120 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. s133 00:10:49.120 --> 00:10:59.080 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. s134 00:10:59.080 --> 00:11:06.960 So, you're basically say, "Here's some markdown explaining how we find out the number of widgets we sold last month." s135 00:11:08.600 --> 00:11:14.520 And of course, here comes the results back and our agent nicely formats that. s136 00:11:14.520 --> 00:11:18.440 Who in here started playing with MCP apps? s137 00:11:19.480 --> 00:11:20.200 Yeah. s138 00:11:20.200 --> 00:11:22.800 So, that was I think you're introduced in the spec in July. s139 00:11:22.800 --> 00:11:29.040 That's something I'm going to talk about later on, like 5 minutes based on this little clock. s140 00:11:29.040 --> 00:11:31.720 Um Okay. s141 00:11:31.720 --> 00:11:33.000 Use case number two. s142 00:11:33.000 --> 00:11:38.320 So, for DevOps engineers, support folks, our platform is very well known. s143 00:11:38.320 --> 00:11:40.040 It's been around for a long time. s144 00:11:40.040 --> 00:11:46.960 The docs, the PDFs, the GitHub projects, the Stack Overflow questions, my blog posts, they're all out there. s145 00:11:46.960 --> 00:11:48.200 The LLM's been trained on it. s146 00:11:48.200 --> 00:11:50.960 They know what to look at if a query is slow. s147 00:11:50.960 --> 00:12:01.280 But, I don't trust an LLM to drop an index, to build an index even, to do anything in the database for me. s148 00:12:01.280 --> 00:12:05.760 I want it to give me advice and then I'll action that advice. s149 00:12:05.760 --> 00:12:11.720 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. s150 00:12:11.720 --> 00:12:13.800 Does that sound crazy? s151 00:12:13.800 --> 00:12:19.720 So, how do I use an agent or LLM to get help with a production system that's running slow? s152 00:12:19.720 --> 00:12:24.240 Everyone here has a test environment that mirrors production, right? s153 00:12:24.920 --> 00:12:26.920 No? s154 00:12:28.520 --> 00:12:37.880 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. s155 00:12:37.880 --> 00:12:41.320 So, there's a good chance your performance issue would replicate over there. s156 00:12:41.320 --> 00:12:45.040 You can have your agent go attack, not attack, that's not the right word. s157 00:12:45.040 --> 00:12:46.720 That's the right word actually sometimes. s158 00:12:46.720 --> 00:12:56.320 You can have your agent go interrogate that safer environment to investigate and try out different performance um tricks. s159 00:12:56.320 --> 00:13:00.320 So, I am looking to give the LLM's read-only access, but that's not enough. s160 00:13:00.320 --> 00:13:08.440 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. s161 00:13:08.440 --> 00:13:17.440 Um we can do that a couple different ways, but for me, the best place to always implement security for the database is where? s162 00:13:18.560 --> 00:13:20.240 At the database. s163 00:13:20.240 --> 00:13:30.040 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, s164 00:13:30.040 --> 00:13:30.480 right? s165 00:13:30.480 --> 00:13:35.880 But if you put security at the database layer, more times than not you're going to be okay. s166 00:13:35.880 --> 00:13:41.240 The agents and LLMs are really, really good at finding and fixing performance issues. s167 00:13:41.240 --> 00:13:43.560 This is probably the easiest demo for me to do. s168 00:13:43.560 --> 00:13:47.800 I don't have time to do demo, but I've written a custom tool. s169 00:13:47.800 --> 00:13:58.160 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. s170 00:13:58.160 --> 00:14:00.280 We have something called a cost-based optimizer. s171 00:14:00.280 --> 00:14:06.040 So, when you ask queries, the plans that get generated, they don't get generated based on rules of thumb. s172 00:14:06.040 --> 00:14:11.200 We look at the profile of the data, like how many unique values are in this column. s173 00:14:11.200 --> 00:14:12.320 Yada yada yada. s174 00:14:12.320 --> 00:14:19.560 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. s175 00:14:19.560 --> 00:14:24.320 So, I'm not generating 15 tools that are single-use tools. s176 00:14:24.320 --> 00:14:29.280 I'll generate three or four tools that cross categories, and each of those tools have options. s177 00:14:29.280 --> 00:14:31.760 So, my agent can see, oh, here's a performance tuning tool. s178 00:14:31.760 --> 00:14:33.240 It can do six things. s179 00:14:33.240 --> 00:14:36.720 One of those is like generating uh a performance profile report. s180 00:14:36.720 --> 00:14:39.440 We have a feature called um AWR. s181 00:14:39.440 --> 00:14:41.000 I'll let it generate a report. s182 00:14:41.000 --> 00:14:44.800 One of the other things I'll let it do is is generate statistics. s183 00:14:47.960 --> 00:14:53.920 This ties in closely to the first use case, schema exploration and documentation. s184 00:14:54.440 --> 00:14:56.120 Man, I'm running out of time. s185 00:14:56.120 --> 00:15:00.120 So, natural language to SQL is really awesome. s186 00:15:00.120 --> 00:15:09.560 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. s187 00:15:09.560 --> 00:15:14.680 We need that data, but it's a nightmare for a lot of these systems. s188 00:15:14.680 --> 00:15:19.560 Has anyone started a job in the last 6 months? s189 00:15:20.280 --> 00:15:30.360 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, s190 00:15:30.360 --> 00:15:37.680 all of the all of the inside jokes are documented, where the data model is explained. s191 00:15:37.680 --> 00:15:47.680 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. s192 00:15:47.880 --> 00:15:50.640 Yeah, it's a big Confluence page. s193 00:15:50.640 --> 00:16:03.760 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. s194 00:16:03.760 --> 00:16:07.080 So, it's another context engineering exercise. s195 00:16:07.080 --> 00:16:18.720 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. s196 00:16:18.720 --> 00:16:30.440 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, s197 00:16:30.440 --> 00:16:32.280 it's just a it's just just a huge waste. s198 00:16:32.280 --> 00:16:41.200 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. s199 00:16:41.200 --> 00:16:49.440 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. s200 00:16:49.440 --> 00:16:53.640 So, we got to get them the information they need to to make it easier to use our databases. s201 00:16:53.640 --> 00:17:02.040 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. s202 00:17:03.600 --> 00:17:08.000 So, when you go look at our tools, we have something called schema information. s203 00:17:08.000 --> 00:17:14.640 So, I'll say, "Hey, Codex, Claude, whatever, I've got a new um environment. s204 00:17:14.640 --> 00:17:21.720 I need you to go look into it and see how laid out, find this, and let's go summarize the information. s205 00:17:21.720 --> 00:17:33.600 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. s206 00:17:33.600 --> 00:17:38.120 Hey, show me all the tables, show me all the columns, show me all of the comments. s207 00:17:38.120 --> 00:17:42.480 Let's go read five rows out of each table to see if the data has what we looks like. s208 00:17:42.480 --> 00:17:51.040 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. s209 00:17:51.040 --> 00:17:57.600 You can go verbose, slim, medium, just like my pants, and uh it's got filtering. s210 00:17:57.600 --> 00:18:02.072 So, you can give it keywords, and it just looks for specific things in the data. s211 00:18:02.072 --> 00:18:02.440 [snorts] s212 00:18:02.440 --> 00:18:13.960 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. s213 00:18:13.960 --> 00:18:26.560 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, s214 00:18:26.560 --> 00:18:30.520 organize it, and and put it back into the database. s215 00:18:30.520 --> 00:18:37.720 This is also it's easier to one-shot SQL queries when you have natural language to SQL exercises. s216 00:18:39.120 --> 00:18:44.680 This is what the data looks like in the database after I've properly annotated a table. s217 00:18:44.680 --> 00:18:50.400 So, anytime I do a run or a bike ride or whatever, it goes into my Strava account. s218 00:18:50.400 --> 00:18:54.480 I'm a nerd, so I have an API on that data, and I store it in my database. s219 00:18:54.480 --> 00:19:03.040 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. s220 00:19:03.040 --> 00:19:09.560 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?" s221 00:19:09.560 --> 00:19:15.560 and it looks at my personal workout history, it it gets to that much easier with this with this info. s222 00:19:15.560 --> 00:19:19.200 And the nice thing about this with MCP is AI and LLM agnostic. s223 00:19:19.200 --> 00:19:25.360 It's going to work for everything as long as the MCP server and the tools are there. s224 00:19:27.560 --> 00:19:30.120 Okay, so this might be the most important thing I talk about, security. s225 00:19:30.120 --> 00:19:31.840 So, I got 40 seconds. s226 00:19:31.840 --> 00:19:33.600 We'll just end on this. s227 00:19:33.600 --> 00:19:42.880 Um we need to know who is looking at the information in the database before we return any data back to them. s228 00:19:42.880 --> 00:19:48.480 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. s229 00:19:48.480 --> 00:19:59.920 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. s230 00:19:59.920 --> 00:20:03.280 We pipe you through your organization single sign-on. s231 00:20:03.280 --> 00:20:13.080 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, s232 00:20:13.080 --> 00:20:14.680 Jeff is an HR manager. s233 00:20:14.680 --> 00:20:18.440 He's allowed to see everyone's salary." s234 00:20:19.240 --> 00:20:22.120 But no one else outside that org can. s235 00:20:22.120 --> 00:20:33.600 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 s236 00:20:33.600 --> 00:20:34.280 to the agent. s237 00:20:34.280 --> 00:20:36.440 We call that deep data security. s238 00:20:36.440 --> 00:20:38.720 I'm out of time. s239 00:20:38.720 --> 00:20:41.360 I covered the big stuff. s240 00:20:42.480 --> 00:20:44.560 We thought a lot about security at Oracle. s241 00:20:44.560 --> 00:20:48.240 We want this stuff to be easy, but we want it to be safe. s242 00:20:48.240 --> 00:20:54.200 We are building MCP apps, so you can have the database interface GUI directly in your agent. s243 00:20:54.200 --> 00:20:55.649 That's coming later this year. s244 00:20:55.649 --> 00:20:56.960 [snorts] s245 00:20:56.960 --> 00:20:58.520 We have skills. s246 00:20:58.520 --> 00:21:01.840 The skills can be delivered via tools. s247 00:21:02.120 --> 00:21:03.880 We support automated rag pipelines. s248 00:21:03.880 --> 00:21:15.920 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. s249 00:21:15.920 --> 00:21:21.120 And when you want to learn more about any of this stuff, we have the easiest URL oracle.com/mcp. s250 00:21:21.720 --> 00:21:28.920 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. s251 00:21:28.920 --> 00:21:31.040 If you missed out on the plushy, we have more. s252 00:21:31.040 --> 00:21:32.984 Thanks, everyone. s253 00:21:32.984 --> 00:21:34.984 [applause and music]