Build-Time vs. Run-Time: Why Dev Tools Fail in Production — Averi Kitsch & Prerna Kakkar, Google
Database tools safe for supervised development can be destructive at runtime. Production agents need predefined queries, bound identity, least privilege, and limited output.
Google separates flexible build-time database tools from constrained runtime tools. In one demo, an agent responded to an error by deleting a table. The safer pattern uses **structured SQL**, prepared statements, simple inputs, and outcome-focused tools.
Treat production tool schemas as security boundaries. Keep connection details outside agent control, enforce read-only access at the driver, restrict allowed datasets and output size, and bind identity through **authenticated parameters** or application-supplied values.
Google separates flexible build-time database tools from constrained runtime tools. In one demo, an agent responded to an error by deleting a table. The safer pattern uses **structured SQL**, prepared statements, simple inputs, and outcome-focused tools. Treat production tool schemas as security boundaries. Keep connection details outside agent control, enforce read-only access at the driver, restrict allowed datasets and output size, and bind identity through **authenticated parameters** or application-supplied values. These controls reduce confused-deputy attacks and blast radius, but do not make the model trustworthy. Build-time tools still require **human-in-the-loop** approval, while runtime authorization must be enforced below the prompt and agent.
This turns broad least-privilege guidance into a database-specific design split: permissive tools may aid supervised building, but production agents need narrow schemas, structured queries, driver-enforced access, bound identity, and capped results. It confirms that prompts cannot provide authorization and adds a concrete destructive failure showing why enforcement must sit beneath the model.