Averi Kitsch builds infrastructure that lets AI applications use databases while keeping credentials, queries, and access to users’ data under application control. In her joint talk with Prerna Kakkar, she identified herself as a staff software engineer working on Google Cloud databases and technical lead for MCP Toolbox for Databases, an open-source database server implementing the Model Context Protocol. Their presentation explains why tools designed to help developers explore and administer databases need different restrictions when an agent uses them to serve customers.
From medical imaging to serverless developer tools
Before Google, Kitsch developed image-analysis software and processing pipelines in medical-imaging research. Her personal site describes that work, and the University of Washington’s Quantitative Breast Imaging Lab lists her among its alumni as a research scientist and engineer.
Her earlier work at Google focused on developer experience for serverless computing. In her 2019 article on moving ETL processes to Cloud Run, she argued for retaining existing SQL, shell, or Python scripts when a larger processing platform would introduce unnecessary complexity. Managed containers could run the familiar transformation logic, with queues, retries, logging, and authenticated service calls supplying the surrounding infrastructure. The article gives a concrete example of her practical approach: improve how existing code runs without requiring developers to rewrite the business logic.
Building database infrastructure for AI applications
MCP Toolbox: MCP Toolbox supports database-connected agents through configured data sources, authentication, connection pooling, telemetry, and specialized tools. Developers can define the operations their applications need while the server handles database access. Kitsch also co-authored the December 2025 announcement connecting Antigravity to Google Cloud database and analytics services, bringing these tools into an AI development environment.
Restricting database access for customer-facing agents
Kitsch and Kakkar’s joint presentation makes the distinction between exploration and production concrete. A developer investigating an unfamiliar database may need an agent to generate SQL for a complex analytical question. A customer-facing agent canceling an order can instead call a predefined, parameterized query. Broad administrative tools require human oversight: their presentation includes an example in which an agent deleted a table to start fresh without safeguards. They recommend limiting production agents to the operations the customer workflow actually requires.
Their security argument also explains why fixed SQL alone is insufficient. An agent can still retrieve the wrong person’s records if a prompt controls the user identifier passed into an otherwise legitimate query. They separate user, application, and agent identities: an application may need access to several services, while its agent should access only the data permitted for the end user. Their triage-agent example illustrates the risk. A malicious instruction inserted into a ticket could persuade an agent with broad privileges to query employee salaries and post them back to that ticket.
Toolbox reduces the agent’s control in stages. Developers configure connection details outside the model, then restrict database access through read-only enforcement, allowed datasets where supported, and output limits. Custom tools replace arbitrary SQL generation with predefined statements and typed parameters. Sensitive identity parameters receive further protection: the application can bind an authenticated user identifier directly to a tool, or the tool can validate a signed identity token and extract the relevant claims. In their flight-lookup example, the agent supplies a date while authenticated identity determines whose flights it may retrieve. A prompt claiming to be another traveler cannot choose that identity parameter.
Tool usability, experimentation, and production tradeoffs
The presentation treats tool usability as part of dependable execution. Outcome-oriented tools can complete a task with fewer calls than a collection of small API operations. Descriptions should explain when and how to use a tool; flat, simple inputs reduce the complexity of constructing valid arguments. Separating read and write tools lets applications approve reads automatically while requesting confirmation for changes. Actionable errors give agents enough information to correct an input or retry an operation instead of leaving them with a generic failure code.
Kitsch’s introduction of Toolbox’s npm package considers the tradeoff between easy experimentation and predictable production execution. A single command lowers the effort required to try Toolbox, but dynamically downloading executable packages introduces supply-chain exposure. Her discussion of agent memory and context graphs explores a further question: how agents might retain decisions across sessions and use accumulated context to make more useful recommendations. That is an area of exploration alongside her established work on controlled database access.
Averi Kitsch and Prerna Kakkar show why flexible database tools become dangerous when exposed to end users—and how predefined SQL, restricted privileges, and application-bound identity turn an agent tool into a production interface.
Keep control-plane and arbitrary SQL tools in human-supervised development workflows; production agents should invoke predefined operations with narrow, typed inputs.
Treat model-derived parameters as untrusted. Connection details, SQL statements, permissions, and authenticated user identity belong under application or server control.
Bound or authenticated parameters prevent a prompt from substituting another user’s identity; the final tool can expose only nonsensitive choices such as a date.
▶ Watch ↗