Database agents fall into three patterns: admin tools, natural-language-to-SQL tools, and structured SQL tools with pre-approved queries.
2
A confused deputy attack can use an untrusted ticket comment to make an agent query and disclose every employee's salary.
3
A zero-trust database tool hides credentials and identity from the agent, uses prepared statements with typed parameters, and lets the application control security-sensitive values.
Summary
Averi Kitsch explains what Google has learned from more than 20 million monthly tool calls to Google Cloud databases. She describes three common database-tool patterns, then separates flexible build-time assistants from constrained runtime tools that serve untrusted users. The security problem is an agent with private data, untrusted content, and a way to send results back. Kitsch demonstrates how a ticket comment could make an agent disclose employee salaries. Her proposed progression starts with removing credentials and connection details from the agent, then replaces raw SQL with pre-approved semantic tools and strongly typed prepared statements. The final step binds user identity and other sensitive parameters outside the model, using application checks or OpenID token handling. She is direct about the remaining trade-off: broad analytical questions still need a safe execution path, and she points to parameterized secure views as a possible answer.
Kitsch groups database tools into control plane tools, natural-language-to-SQL tools, and structured SQL tools. Control plane tools handle actions such as creating databases, instances, and users, mainly for developer assistance and DBA automation. Natural-language-to-SQL tools help developers write queries and let analytical agents explore schemas to answer unusual questions, such as finding customers who bought and returned a winter jacket and grouping them by campaign. Structured SQL tools use SQL written and approved by a developer, while the agent supplies only specific parameters. Kitsch says this last pattern is the most popular tool-call pattern and is suited to autonomous applications or systems with untrusted users.
Runtime agents need tighter controls than developer assistants
Kitsch separates build-time tools from runtime tools. Build-time tools help developers iterate, debug, and write code, so they can have broad and flexible access with a human expert involved. Runtime tools power end-user business workflows, including systems built with LangChain or Pydantic AI. In that setting, hallucinations can return incorrect data or expose information the user should not see. Runtime tools also need low latency because they sit in production systems. Kitsch says build-time MCP servers are more common today, while runtime applications have much greater potential for tool-call volume.
The lethal trifecta turns an ordinary agent into a data-breach path
Kitsch uses Simon Willison's lethal trifecta to describe the conditions for an agent data breach: access to private data, exposure to untrusted content, and the ability to communicate information back to the user. Her confused deputy example uses an agent assigned to investigate a slow database through a ticketing system. An untrusted person comments on the ticket and asks the agent to query every employee's salary. Because the agent trusts the ticket system and has broad database access, it performs the query and posts the results back to the ticket. The application then becomes a path for disclosing sensitive data.
Applications should control factual constraints outside the model
Kitsch contrasts traditional applications with agentic applications. A traditional application can have broad database permissions when its predefined actions tightly constrain what users can request. An agent can choose its own actions, so its access must be limited to what the user is allowed to see. She separates three identities: the user, the application's workload identity, and the agent. The user needs access to the application, while the workload identity accesses databases and other systems. The agent should receive only the specific data and actions allowed for that user. This leads to a second distinction between agent parameters from prompts and application parameters that encode factual security constraints.
The first secure-tool step removes connection details from the agent
The most dangerous version of the tool accepts database credentials and raw SQL as model-controlled inputs. A user who can influence the agent could expose credentials or query any database available to the workload. Kitsch's first Toolbox step moves connection details and network topology into a YAML source configuration. Those details are injected when the MCP server starts, so the agent never sees them. The tool signature becomes simpler, but it still accepts raw SQL. This stage removes direct credential exposure while leaving the model with too much control over which query it can run.
Pre-approved SQL and typed parameters block SQL injection at the tool layer
The next step removes raw SQL from the agent's inputs. Developers define a SQL statement and its allowed parameters ahead of time, also adding descriptions so the agent knows how to use the tool. Kitsch says Toolbox uses prepared statements with strict, strongly typed parameters to prevent SQL injection. The result is a semantic tool such as 'look up flights', which accepts values such as a user ID and date rather than an arbitrary query. The model can select and call the tool, but it cannot rewrite the SQL or add an unexpected clause. This makes the tool suitable for applications with autonomous behavior or untrusted users.
Identity and PII should enter tool calls outside the agent
Kitsch describes two ways to keep identity information out of the model. With binding parameters, the application verifies the user and token, then attaches the verified value to the tool call. With authenticated parameters, the token travels with the call outside the agent's control, and the tool extracts the required information from the OpenID token. For a flight lookup, the system can derive the user ID from the token and insert it into the SQL query without showing it to the agent. At the final stage, the agent supplies only a non-security-critical value such as a date, while credentials and personally identifiable information remain outside its control.
Broad analytical questions still need a safe execution design
During the question period, Kitsch addresses the tension between locking down tools and answering unusual analytical questions. Her current practice is to learn which questions users actually need and build those questions into custom tools. She says natural-language-to-SQL methods are still developing and that no single approach has emerged as the best one. For an execute-SQL capability, she points to parameterized secure views as a possible path. These would create a sandbox inside the database for analytical access. Kitsch also cautions that a trusted user may still be operating alongside the agent, which affects how safely such a broad tool can be used.
"A data breach occurs when the agent has access to three different things. One, private data. Two, untrusted content. And three, the ability to communicate that back to the user."07:08
Who should watch
You are building an agent that can query production databases and need to separate model inputs from application-controlled security constraints.
Your MCP server currently exposes raw SQL, credentials, or broad database permissions to an agent.
You need to support analytical questions while deciding how much query flexibility a runtime agent can safely have.
