WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=9R--1tg45Jg

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/9R--1tg45Jg.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.480 --> 00:00:17.360
Hey everyone, how all of you are doing today?

s3
00:00:17.520 --> 00:00:18.880
Yeah.

s4
00:00:18.880 --> 00:00:20.960
Uh so nice to meet you everyone.

s5
00:00:20.960 --> 00:00:26.560
Uh today uh I and my friend Avery are going to talk about build time versus runtime.

s6
00:00:26.560 --> 00:00:30.400
Why your developer tools fail in production.

s7
00:00:30.480 --> 00:00:33.440
So firstly, know about us.

s8
00:00:33.440 --> 00:00:34.399
Hi everybody.

s9
00:00:34.399 --> 00:00:39.360
I'm Avery Kit and I'm a staff software engineer working on Google Cloud databases.

s10
00:00:39.360 --> 00:00:51.360
I'm currently the technical lead for MCP toolbox for databases, our open-source uh database MCP server and our Google Cloud MCP server um maintainer.

s11
00:00:51.360 --> 00:01:04.320
Hi, I'm Pna and I am currently working as senior software engineer at Google and I am currently tech lead for Eval bench which is the evaluation framework for all your agent tech MCP and skills need

s12
00:01:04.320 --> 00:01:08.720
and I'm also an active contributor to MCP toolbox.

s13
00:01:09.360 --> 00:01:12.799
So today we are going to cover three areas broadly.

s14
00:01:12.799 --> 00:01:16.799
We will firstly start with the history of MCP at Google.

s15
00:01:16.799 --> 00:01:29.920
Then we will cover on the common tool patterns that we have found from our own work and practices and how did we use all those practices to build some tools for database access and how you can use them

s16
00:01:29.920 --> 00:01:38.560
and then lastly we will talk about security guard rails how you can stop data leaks using identity aware guardrails.

s17
00:01:38.960 --> 00:01:42.799
So let's get to know the background quickly.

s18
00:01:42.799 --> 00:01:45.680
Um I'll talk about MCB toolbox for database.

s19
00:01:45.680 --> 00:01:50.640
It's an open-source self-managed uh serving that we provide.

s20
00:01:50.640 --> 00:01:55.040
Uh it has currently about 15.7K GitHub stars.

s21
00:01:55.040 --> 00:02:00.079
We have 132 plus active contributors across 40 plus different databases.

s22
00:02:00.079 --> 00:02:09.599
It's highly customizable framework and basically we provide you with connection pooling integrated O and you don't even need to care about the observability.

s23
00:02:09.599 --> 00:02:12.879
You will get all of them out of the box.

s24
00:02:12.879 --> 00:02:23.120
Then if you don't want to do a self-managed one but you want to have a hosted scaled version, we provide something as Google managed MCP.

s25
00:02:23.120 --> 00:02:24.640
It's fully managed.

s26
00:02:24.640 --> 00:02:34.879
Uh you can plug it across various agents and ids or harnesses like Gemini CLI, anti-gravity CLI, cloud code, you name any.

s27
00:02:34.879 --> 00:02:46.319
uh it's co uh it's governed and the discovery is simple and we also provide model armor which provides secure access management and identity control.

s28
00:02:46.319 --> 00:02:56.239
So combined with uh the managed version of MCP and the MCP toolbox last month we had 20 million tool calls.

s29
00:02:56.800 --> 00:03:01.360
Um some of the common tool patterns that we have observed specifically for databases.

s30
00:03:01.360 --> 00:03:04.800
So I'm going to quickly talk about them.

s31
00:03:04.800 --> 00:03:07.440
Firstly uh is the control plane tools.

s32
00:03:07.440 --> 00:03:11.280
What we like to call them is admin tools or manage tools.

s33
00:03:11.280 --> 00:03:14.319
It is basically in developer assistance space.

s34
00:03:14.319 --> 00:03:21.440
So it will help you create like instance, manage your instance, create your databases, manage your databases.

s35
00:03:21.440 --> 00:03:24.319
It will help you with all your DBA needs.

s36
00:03:24.319 --> 00:03:26.560
But you need to be very careful.

s37
00:03:26.560 --> 00:03:34.000
You need to be you need to have a human in the loop because we don't want to carry out any dangerous activities.

s38
00:03:34.000 --> 00:03:43.840
Um so these tools are built on already provisioned public API so you get monitoring and other things out of the box.

s39
00:03:44.239 --> 00:03:48.319
Next one is natural language to SQL or NL2SQL tools.

s40
00:03:48.319 --> 00:03:56.319
So basically we are relying on a tool called as execute SQL and with the help of agent we generate raw SQL queries.

s41
00:03:56.319 --> 00:04:01.680
So you can use this cases where you don't know uh what queries you would require beforehand.

s42
00:04:01.680 --> 00:04:06.159
So you will get all these queries out of the out of the box.

s43
00:04:06.159 --> 00:04:14.480
So it it focuses on the developer assistance and analytical agents and uh you can use it for flexible explorations.

s44
00:04:14.480 --> 00:04:26.479
So for example, we have one of the examples like find all customers in California who bought a winter coat in July and returned it within 14 days and group them by the marketing campaign

s45
00:04:26.479 --> 00:04:28.960
that originally acquired them.

s46
00:04:28.960 --> 00:04:35.759
So this is one of the queries where uh you can use this tool uh to get your answers.

s47
00:04:37.360 --> 00:04:50.320
But then we have something called a structure SQL tools which is getting quite popular and this targets mainly the production use cases where you know like what SQL query you want to use and you want to have security

s48
00:04:50.320 --> 00:05:03.919
built in and uh you the parameters are already configured so uh you prevent SQL injection and ensure highly controlled access by restricting agent to predefined logic.

s49
00:05:03.919 --> 00:05:10.240
It also helps you with your latency needs and reduce the hallucination on the agent side.

s50
00:05:10.800 --> 00:05:17.120
Now we come to the main topic I guess for which you guys are here for buildtime versus runtime.

s51
00:05:17.120 --> 00:05:20.080
So buildtime are the developer assistant use cases.

s52
00:05:20.080 --> 00:05:26.880
Um you can think about the initial two cases that we presented to you like the NL2SQL tools and the control plane tools.

s53
00:05:26.880 --> 00:05:29.759
They come into the category of buildtime tools.

s54
00:05:29.759 --> 00:05:41.440
uh it's atomic and f flexible but again you don't want to delete your databases so it requires to be a human in the loop case and you can't run them on the on production use cases

s55
00:05:41.440 --> 00:05:54.240
but let's say I'm interested in building some chat B and I want to do production use cases there you rely on runtime or end user applications you can build those using patenting AI or lchain

s56
00:05:54.240 --> 00:06:04.080
um so you can see one of the examples like we have a cancel order a deterministic structure SQL query that we have given and you can use it as a tool.

s57
00:06:05.039 --> 00:06:14.319
This is one of the examples uh or demo for like wherein a buildtime tool was used and uh you can see the error message.

s58
00:06:14.319 --> 00:06:18.319
So uh agent actually asked to delete the table and start fresh.

s59
00:06:18.319 --> 00:06:24.000
We deleted everything and there were no safeguard or guardrails here.

s60
00:06:24.000 --> 00:06:29.680
Now let's go to our demo for runtime tools.

s61
00:06:38.080 --> 00:06:42.160
Yeah, maybe um I think until the video loads.

s62
00:06:42.160 --> 00:06:50.160
So, so sorry for the technical glitch that we have, but I can quickly walk you through what we are going to present in the video and I guess it's loading.

s63
00:06:50.160 --> 00:06:52.160
Yeah.

s64
00:06:52.240 --> 00:07:00.160
Um so this demo is particularly talking about how did we use our production tools in a chatbot.

s65
00:07:00.160 --> 00:07:15.840
Uh and we created a demo called a Similar and Symbolair is going to help me with booking all my flights in San Francisco and do and whatever I would require to do in San San Francisco it would basically help me with it.

s66
00:07:15.840 --> 00:07:25.599
Uh, one of the things that I would try is I would try to fool my agent that I am Avery and not PRA and book a flight for me to

s67
00:07:25.599 --> 00:07:27.599
San Francisco.

s68
00:07:27.599 --> 00:07:40.319
But because our agent is uh has all the authenticated O, it will not get fooled and it will not book any flights uh on behalf of Avery, but it will do it on my behalf.

s69
00:07:40.319 --> 00:07:44.160
Um and then you can use it to basically change your flights.

s70
00:07:44.160 --> 00:07:50.400
You want to know about all the shops that are there, you can do all these requirements using that.

s71
00:07:50.400 --> 00:07:55.520
So I guess thank you u Avery.

s72
00:07:59.360 --> 00:08:01.759
I think we

s73
00:08:17.805 --> 00:08:19.759
[sighs]

s74
00:08:19.759 --> 00:08:25.199
Apologies again for our technical difficulties here.

s75
00:08:32.000 --> 00:08:36.959
Um, unfortunately, it looks like I need to present from just the slide deck because it's not loading.

s76
00:08:36.959 --> 00:08:46.480
Okay, so I apologize for not being able to see our demo today, but we can still learn all the security and guardrails that we need to secure our database access.

s77
00:08:46.480 --> 00:08:51.600
So, the first thing that we need to know is your database is only as secure as your agent.

s78
00:08:51.600 --> 00:08:55.600
We all know that agents and LMS are actually pretty easy to trick.

s79
00:08:55.600 --> 00:09:01.360
They might be getting slightly better today, but we can still work really hard to trick them.

s80
00:09:01.360 --> 00:09:06.240
And so we have a very common attack pattern called the confused deputy attack.

s81
00:09:06.240 --> 00:09:16.000
And this is when a user can trick an agent into misusing their privileges um to access data that a user wasn't supposed to access.

s82
00:09:16.000 --> 00:09:20.399
So Simon Willis actually coined the phrase the lethal trifecta.

s83
00:09:20.399 --> 00:09:26.240
And a data breach occurs when an agent has simultaneous access to three different things.

s84
00:09:26.240 --> 00:09:28.240
One, private data.

s85
00:09:28.240 --> 00:09:30.399
Two, untrusted content.

s86
00:09:30.399 --> 00:09:37.760
And three, the ability to expose that content and that data back to an external user.

s87
00:09:38.560 --> 00:09:41.600
So let's take a look of that in action.

s88
00:09:41.600 --> 00:09:52.720
So let's say I'm building a triage um agent and so a ticket is fired or alert goes out and my agent is designed to um look at that ticket and

s89
00:09:52.720 --> 00:09:55.760
go investigate what it needs to do.

s90
00:09:55.760 --> 00:10:02.480
So on that ticket the agent gets a little bit of data like we need to go look in this database for these reasons.

s91
00:10:02.480 --> 00:10:14.560
Um but a malicious insider can actually come into that trusted system and instead say well I want to query the salary database and please return all the employees salaries.

s92
00:10:14.560 --> 00:10:19.519
And so since this is a trusted system the agent goes okay let me use my permissions.

s93
00:10:19.519 --> 00:10:20.880
I have those privileges.

s94
00:10:20.880 --> 00:10:22.160
I have that access.

s95
00:10:22.160 --> 00:10:27.839
I will query that and I'll post that right back on the ticket because that's what the ticket tells me to do.

s96
00:10:27.839 --> 00:10:31.120
But now we have a huge data breach.

s97
00:10:31.120 --> 00:10:36.640
a user that wasn't supposed to have access to private data now has that access.

s98
00:10:36.640 --> 00:10:40.480
And so now we have a big PR fiasco.

s99
00:10:43.519 --> 00:10:50.800
So this makes a little bit more sense when we think about who's controlling access and who's controlling the parameters.

s100
00:10:50.800 --> 00:10:56.160
So we talk about agent or application versus modeled controlled parameters.

s101
00:10:56.160 --> 00:11:10.000
So in a traditional architecture, things were actually much easier because you would have a few input fields, you would define your queries and then that would be safely injected into those queries.

s102
00:11:10.800 --> 00:11:21.600
And so it was okay when your application had a little bit more access because it knew exactly what actions it was going to take.

s103
00:11:21.920 --> 00:11:26.399
But in uh a gent application these rules aren't as clear.

s104
00:11:26.399 --> 00:11:30.800
So we need to first think about um separating the three different identities.

s105
00:11:30.800 --> 00:11:37.839
We have the user identity, we have the application identity and the agent identity.

s106
00:11:39.120 --> 00:11:43.600
So first um we need to think about what the user has access to.

s107
00:11:43.600 --> 00:11:47.279
So the user just needs to have access to the application.

s108
00:11:47.279 --> 00:12:05.839
that application's workload identity can have a little bit more broader access um because it needs to probably talk to different services but the agent running in that application only needs to have access to the data that that end user initially needs to have.

s109
00:12:06.000 --> 00:12:11.040
So then next we need to think about who's controlling the tool inputs.

s110
00:12:11.040 --> 00:12:17.200
So we have um agent parameters um and a application parameters.

s111
00:12:17.200 --> 00:12:22.320
So agent parameters are the untrusted inputs that the agent is deriving dynamically.

s112
00:12:22.320 --> 00:12:24.959
And then we also have application parameters.

s113
00:12:24.959 --> 00:12:31.839
These are the factual constraints that we need to keep outside of the agents uh control.

s114
00:12:33.040 --> 00:12:33.760
Okay.

s115
00:12:33.760 --> 00:12:37.680
So now let's look at the evolution of a secure tool.

s116
00:12:37.680 --> 00:12:41.120
Here we have a fully modeled control tool.

s117
00:12:41.120 --> 00:12:44.000
And so essentially the agent here is a super user.

s118
00:12:44.000 --> 00:12:53.200
It has access to database credentials, the host, the port, the connection details, and even the raw SQL query.

s119
00:12:53.440 --> 00:12:58.240
And so we're only secure as um the agent here.

s120
00:12:58.240 --> 00:13:02.560
And we can really easily again trick the agent into exposing all of this data.

s121
00:13:02.560 --> 00:13:07.600
And now we have access to essentially any database in the system.

s122
00:13:08.000 --> 00:13:13.040
So Toolbox solves for this um by introducing a source primitive.

s123
00:13:13.040 --> 00:13:28.160
So we move the connection details out of the agents control and in toolbox um a user will preconfigure the connection details in a YAML file and then when we start our MCP server those are safely injected and so we do not have to have the agent

s124
00:13:28.160 --> 00:13:31.120
um to have access to that.

s125
00:13:33.279 --> 00:13:38.160
So we can add a little bit more control to our um source security as well.

s126
00:13:38.160 --> 00:13:42.320
Our number one request that we get from customers is read only restrictions.

s127
00:13:42.320 --> 00:13:48.959
We want to be able to remove all right ability from agents if we need that specific uh user journey.

s128
00:13:48.959 --> 00:13:58.160
So this means removing right tools but also down to the database driver ensuring that we can only do read only queries.

s129
00:13:58.160 --> 00:14:09.680
If we're also concerned about again blast radius um and securing all of our tables and our databases um some of our cloudnative databases have this concept of allowed data sets.

s130
00:14:09.680 --> 00:14:19.360
So again we can add that like enum to our source in order to continue to restrict um the blast radius of um the agents control and lastly is output size.

s131
00:14:19.360 --> 00:14:31.600
You might not actually think that this is a security layer, but if again the agent gets into the wrong hands, we can reduce that blast radius by saying uh the agent can only uh grab this much data.

s132
00:14:31.600 --> 00:14:36.320
So we're not overwhelming both our agent or our database.

s133
00:14:38.240 --> 00:14:41.600
So sweet, we have our configurable sources tool.

s134
00:14:41.600 --> 00:14:47.199
So you can see here that actually now our tool input, our tool signature is very minimalized.

s135
00:14:47.199 --> 00:14:53.920
we only have the SQL string that's um being generated by the agent.

s136
00:14:55.120 --> 00:14:58.320
But this comes to our actual our next pro problem.

s137
00:14:58.320 --> 00:15:02.399
We want to be able to control what the agent is running.

s138
00:15:02.399 --> 00:15:07.920
We don't want the agent to have the ability to generate any SQL um that it can think of.

s139
00:15:07.920 --> 00:15:18.720
So toolbox introduces custom tools and again in our YAML file we can define the exact SQL uh statement that will run very reliable.

s140
00:15:18.880 --> 00:15:22.399
It's a reliable and secure uh SQL query.

s141
00:15:22.399 --> 00:15:26.480
Um this also allows us to customize the tool name and the tool description.

s142
00:15:26.480 --> 00:15:33.920
These are really important for the agent to have the context on how to use this tool um accurately.

s143
00:15:34.000 --> 00:15:40.560
And in the system we use prepared statements with type parameters in order to reduce um SQL injection attacks.

s144
00:15:40.560 --> 00:15:50.639
So we make sure that everything is um we validate all the input types um when we inject that into the SQL for the user.

s145
00:15:52.160 --> 00:15:56.240
Okay, let's dive into a little bit more of best practices for tool quality.

s146
00:15:56.240 --> 00:15:59.759
So we really highly recommend that tools focus on outcomes.

s147
00:15:59.759 --> 00:16:03.120
We really shouldn't be thinking in atomic rest APIs.

s148
00:16:03.120 --> 00:16:06.560
we should think about what the action actually needs to do.

s149
00:16:06.560 --> 00:16:12.320
This also reduces the round trip of needing to make multiple tool calls.

s150
00:16:12.320 --> 00:16:14.959
And again, the descriptions are guidance.

s151
00:16:14.959 --> 00:16:20.399
We shouldn't um duplicate information like input parameters because the agent already has access to that.

s152
00:16:20.399 --> 00:16:27.120
So, writing really good um tool descriptions is very important for accurate tool usage.

s153
00:16:27.120 --> 00:16:31.360
We also recommend that you separate read versus write tools.

s154
00:16:31.360 --> 00:16:44.639
Um by doing this you can automatically approve read tools and but you can also then send write tools uh to the user for um confirmation and this just makes it very much more clear for the agent to use these

s155
00:16:44.639 --> 00:16:47.360
and this is actually uh the next is actionable errors.

s156
00:16:47.360 --> 00:16:51.040
This is the number one thing that I think we can all do better.

s157
00:16:51.040 --> 00:17:03.279
So usually we just return like a generic HTTP error four or four but we all know agents are actually really smart now and so if you give the ability to have an error of that can be retrieded

s158
00:17:03.279 --> 00:17:05.360
the agent can actually take that action.

s159
00:17:05.360 --> 00:17:12.400
So being able to return a error is really important and lastly is simple inputs.

s160
00:17:12.400 --> 00:17:22.640
We see that people try to use these complex maps uh complex primitives to um that an agent needs to be able to build and that is not reliable.

s161
00:17:22.640 --> 00:17:31.360
Using flat structure with um with uh simple inputs will really increase your reliability.

s162
00:17:32.640 --> 00:17:33.520
So sweet.

s163
00:17:33.520 --> 00:17:35.919
Now we're at custom semantic tools.

s164
00:17:35.919 --> 00:17:43.520
You can see that we now have our lookup flights tool that takes in the dynamic parameters such as user ID and date.

s165
00:17:43.520 --> 00:17:49.120
And so now our we're very much more secure because the agent isn't generating that SQL query.

s166
00:17:49.120 --> 00:17:51.760
It doesn't have the ability to kind of go off the rails.

s167
00:17:51.760 --> 00:17:55.760
It only is looking at these very specific inputs.

s168
00:17:57.600 --> 00:18:01.520
But user ID is actually a very sensitive piece of information.

s169
00:18:01.520 --> 00:18:02.720
It is PII.

s170
00:18:02.720 --> 00:18:07.120
we need to also remove that from the ability of the agent's control.

s171
00:18:07.120 --> 00:18:09.200
So we can do this in two different ways.

s172
00:18:09.200 --> 00:18:11.120
We have bounded parameters.

s173
00:18:11.120 --> 00:18:18.720
This is when the application first um authenticates the user and then we can bind that parameter um directly to our tool.

s174
00:18:18.720 --> 00:18:21.039
And so that restricts the agents control of it.

s175
00:18:21.039 --> 00:18:24.720
It actually never sees that user identity.

s176
00:18:24.880 --> 00:18:30.080
But toolbox also solves for this in another way called authenticated parameters.

s177
00:18:30.080 --> 00:18:42.320
This is when we tell the tool that you're going to receive a identity token, an open ID, a signed jot token, and when we call that tool that we want it first to validate that token.

s178
00:18:42.320 --> 00:18:43.600
Is that token real?

s179
00:18:43.600 --> 00:18:44.799
Is that token correct?

s180
00:18:44.799 --> 00:18:49.280
And then we'll extract the user claims from that token for the user.

s181
00:18:49.280 --> 00:18:55.440
And so the claims usually include like a user ID, an email, um an issuer.

s182
00:18:55.440 --> 00:19:05.360
And so it's secured because we're again extracting that user identity out of the agents control and binding that to the tool.

s183
00:19:08.640 --> 00:19:13.600
So now um we're have a much more secure tool.

s184
00:19:13.600 --> 00:19:19.840
We have our lookup flights tool that only takes in a very easy parameter such as date.

s185
00:19:19.840 --> 00:19:25.280
It doesn't have to handle any sensitive information such as PII, user identity.

s186
00:19:25.280 --> 00:19:36.080
And so we're really here now at um our zero trust architecture where we're in full control of everything that we need to be in control of.

s187
00:19:39.520 --> 00:19:42.400
So thank you all for coming to listen to our talk today.

s188
00:19:42.400 --> 00:19:45.280
Again, I apologize for our technical difficulties.

s189
00:19:45.280 --> 00:19:53.600
Uh we highly recommend if you want to learn more about our technologies um that you look at our documentation and our uh GitHub repository.

s190
00:19:53.600 --> 00:20:02.320
I also really want to highlight our eval bench repository because this is how we know that our tools are working well and eval.

s191
00:20:03.600 --> 00:20:07.039
So thank you all for joining us today.

s192
00:20:07.178 --> 00:20:09.178
[applause]