Prerna Kakkar

Prerna Kakkar works on database tools and agent evaluation, connecting what AI assistants can do with how engineers control and test their actions. In her joint presentation with Averi Kitsch, she introduced herself as a senior software engineer at Google, technical lead for EvalBench, and an active contributor to MCP Toolbox for Databases. These roles bring together two practical problems: giving agents useful database access and checking whether they use it reliably.

From applied machine learning to incident analysis

Kakkar studied at Netaji Subhas Institute of Technology from 2014 to 2018. Her early applied machine-learning projects included transaction forecasting, raw-material demand prediction, and medical-image analysis. With Nalin Nanda and Sushama Nagpal, she co-authored a 2019 study of liver-lesion segmentation. Their approach combined a genetically optimized neural-network classifier with cascaded convolutional networks to identify tumor-bearing livers and segment lesions in CT images. Separating liver identification from lesion delineation addressed distinct tasks: locating the organ and tracing abnormalities within it.

Her later collaborative work examined how to extract useful patterns from software logs and incident reports. A 2023 technical disclosure proposed natural-language processing techniques to turn free-form outage and bug records into structured information about recurring problems, affected users, and relevant components. In a 2024 disclosure, Kakkar, Shrey Nagpal, Souvik Paul, and Shubham Sharma proposed feature extraction, dimensionality reduction, clustering, and visualizations to categorize incident documents. These were proposals for reducing the manual work of recognizing operational patterns; they do not establish deployment or measured results.

Database-aware development at Google Cloud

By 2025, Kakkar was writing about database-aware AI development at Google Cloud. She and product manager Hamsa Buvaraghan co-authored the announcement of MCP integrations for Google Cloud databases. Connecting assistants to database context supports schema design, application-code changes after data-model updates, and integration-test data generation. Her AlloyDB walkthrough makes that workflow concrete: provision a cluster and instance, check long-running operations, create a table, insert data, and generate a Python data class from the resulting schema. The wizarding examples carry a substantive point: an assistant can use database context across successive development steps while the developer remains involved.

Designing controlled, reliable database tools

• Predefined SQL tools: Kakkar and Kitsch’s presentation explains why that flexibility needs different controls in an end-user application. Administrative tools and natural-language-to-SQL tools help developers explore questions whose queries are not known in advance. They also give an agent consequential powers: one example describes a tool deleting a table to start fresh without safeguards. For production workflows such as canceling an order, the speakers favor predefined SQL tools that limit execution to specified application logic. Prepared statements and typed parameters reduce SQL-injection risk, while tool names and descriptions help the agent select the intended action.
• Access and identity controls: Their security explanation develops those controls in stages. MCP Toolbox moves database credentials and connection details into a configured source rather than exposing them as model-controlled inputs. Read-only restrictions, allowed datasets, and output limits further constrain access. Fixed SQL still leaves a problem if the model can choose whose records to retrieve. The application can bind an authenticated user’s identity to the tool, or the tool can validate an identity token and extract its claims. In the flight-lookup example, that leaves the agent choosing a date while user identity stays outside its control. This addresses the confused-deputy problem illustrated by a malicious ticket that instructs a privileged triage agent to retrieve employee salaries and post them back to the ticket. The flight demo did not load during the presentation, so the speakers explained its intended behavior rather than demonstrating it live.
• Reliable tool design: The joint presentation also treats tool design as a reliability problem. Outcome-focused tools can accomplish a useful action with fewer calls than a sequence of atomic APIs. Separate read and write tools allow different approval policies; actionable errors give the agent information it can use to recover; simple, flat inputs reduce the difficulty of constructing valid arguments. These recommendations complement access controls by making permitted actions easier to perform correctly.

Testing agent interactions with EvalBench

Kakkar’s evaluation work addresses how to test those interactions. Google Cloud’s collaborative EvalBench project supports multi-turn agent evaluations in which a simulated user guides an agent toward a goal. It records responses, tool calls and arguments, latency, and token use, with separate scoring for tool trajectories, goal completion, and behavior. Examining those records lets a team distinguish a plausible answer from an interaction that actually performs the required actions. Her work on database tooling and evaluation connects controlled capabilities with tests of how agents use them.