Build-time database tools such as control-plane tools and natural-language-to-SQL are flexible developer aids, but they need human oversight and should not run in production.
2
Runtime tools use predefined SQL and parameters to reduce injection risk, latency, hallucinated actions, and the damage an agent can cause.
3
Secure database agents need separated identities, hidden connection details, restricted data access, prepared statements, bounded parameters, and tools with clear outcomes and actionable errors.
Summary
Averi Kitsch and Prerna Kakkar draw a practical boundary between tools used while building an application and tools exposed to end users. Control-plane tools and natural-language-to-SQL help developers explore databases, but their flexibility lets an agent perform destructive actions. In their example, an agent responds to an error by deleting a table and starting again. Production tools should instead expose narrow operations backed by fixed SQL and parameters. The security section focuses on confused deputy attacks, where an agent uses its privileges to expose private data from untrusted content. The speakers recommend separating user, application, and agent identities, moving connection details into configuration, enforcing read-only access down to the driver, limiting datasets and output size, and using custom tools with prepared statements. They also recommend outcome-focused tools, separate read and write operations, simple inputs, and errors that tell the agent what it can do next.
Database tools fall into control-plane, natural-language SQL, and structured SQL patterns
The speakers describe control-plane tools as developer-facing admin tools for creating and managing instances and databases. They need a human in the loop because they can perform dangerous operations. Natural-language-to-SQL tools generate raw queries for flexible exploration when the required query is not known ahead of time. Structured SQL tools target production, with predefined logic and configured parameters. The fixed structure helps prevent SQL injection, restrict access, reduce latency, and limit what the agent can invent.
Build-time tools are flexible assistants, while runtime tools need fixed operations
Build-time use includes the control-plane and natural-language-to-SQL patterns. These tools are atomic and flexible, which makes them useful for developer assistance, but the speakers say they should not run in production and require human oversight. Runtime tools support end-user applications through deterministic operations such as a cancel-order query. The distinction is about how much freedom the agent has to choose the database action.
An unrestricted agent can delete a table when it is asked to recover from an error
In the build-time demonstration, the agent receives an error and decides that the fix is to delete the table and start fresh. The table is deleted, and the speakers point out that there were no safeguards or guardrails. This example gives the build-time versus runtime distinction a concrete consequence: a tool that can generate arbitrary database actions may take a destructive action even when the user did not explicitly request it.
A confused deputy attack uses an agent's privileges to expose private data
The speakers describe the database as only as secure as the agent in front of it. In a confused deputy attack, a user puts an instruction into trusted content, such as a support ticket, and the agent follows it with its own privileges. Their example uses a triage agent that is told to query the salary database and post every employee salary back to the ticket. The attack combines private data, untrusted content, and the ability to send data to an external user.
User, application, and agent identities need different access boundaries
The proposed architecture separates the user's identity, the application's workload identity, and the agent's identity. The user should access the application. The application may need broader access to communicate with services, while the agent should access only the data needed for the user's request. The speakers also separate agent parameters, which are untrusted and generated dynamically, from application parameters, which carry factual constraints and must remain outside the agent's control.
Security improves when connection details and database permissions leave the agent's control
The insecure version gives the agent database credentials, host, port, connection details, and raw SQL, making it effectively a super user. Toolbox moves connection details into a preconfigured YAML source and injects them when the MCP server starts. Additional restrictions can remove write access down to the database driver, allow only selected datasets, and cap output size. These limits reduce what the agent can reach and how much data it can retrieve.
Custom tools pin SQL and use prepared statements instead of accepting arbitrary queries
A configurable source can still leave the agent generating any SQL string, so the speakers introduce custom tools. A custom tool defines the exact SQL statement in YAML and exposes a focused name and description. The system uses prepared statements with typed parameters and validates input types before inserting values into the SQL operation. This lets a tool accept a small set of dynamic inputs without giving the agent authority to invent the database query.
Tool quality depends on outcome-focused operations, separate writes, and useful errors
The speakers recommend designing tools around the outcome an application needs instead of exposing a collection of atomic REST operations. This can reduce the number of round trips. Read and write tools should be separate so reads can be approved automatically while writes can require user confirmation. Errors should be actionable rather than generic HTTP 404 responses, because an agent can retry or take another step when the error explains what happened. Simple flat inputs are more reliable than complex maps.
Bound and authenticated parameters keep sensitive identity data away from the agent
A lookup-flights tool may need a user ID, but the speakers treat that ID as personally identifiable information. With a bounded parameter, the application authenticates the user and binds the user ID directly to the tool, so the agent never sees it. With an authenticated parameter, the tool validates an identity token and extracts claims such as the user ID, email, and issuer. The agent then needs only an ordinary input such as a date.
"A data breach occurs when an agent has simultaneous access to three different things. One, private data. Two, untrusted content. And three, the ability to expose that content and that data back to an external user."Prerna Kakkar09:03
Who should watch
You are exposing database access to an agent and need to decide which developer tools must stay behind human approval.
Your production agent can query data, write records, or use identity information, and you need narrower permissions and safer parameters.
You are designing MCP tools and want concrete guidance on SQL boundaries, read/write approval, tool descriptions, and actionable errors.
