'Build-Time vs. Run-Time: Why Dev Tools Fail in Production - Averi Kitsch & Prerna Kakkar, Google'

Developer tools that work well at build time (developer-assisted, atomic, flexible) can fail catastrophically in production runtime environments unless secur...

By Sean Weldon

Build-Time vs. Run-Time: Why Dev Tools Fail in Production

Abstract

This synthesis examines a structural asymmetry in agentic tool design: interfaces optimized for build-time developer assistance - atomic, flexible, and human-supervised - become severe security liabilities when deployed unchanged into production runtime paths. Drawing on operational evidence from the open-source MCP Toolbox for Databases (15.7K GitHub stars, 132+ contributors, 40+ supported databases) and Google Managed MCP, which together processed approximately 20 million tool calls in one month, the analysis traces the staged evolution of a database tool from fully model-controlled access toward a zero-trust design. Key findings center on identity separation, parameter binding, and driver-level enforcement as mechanisms distinguishing safe production tools from exploitable developer conveniences. The paper concludes with concrete design heuristics - outcome-oriented tools, read/write separation, and flat input structures - applicable to any team deploying LLM agents against operational data stores.

1. Introduction

The Model Context Protocol (MCP) has become a dominant standard for connecting large language model (LLM) agents to external systems, and databases represent one of its most consequential integration targets. As agentic applications transition from developer-supervised prototyping environments into production systems serving end users, the assumptions embedded in early tool designs - assumptions that were reasonable when a human reviewed every action - become load-bearing security properties that frequently fail to hold.

This analysis is organized around a central asymmetry: tools that perform well at build time, where a developer iterates freely, inspects each output, and can reverse mistakes, are not automatically safe at runtime, where an autonomous agent acts on behalf of potentially untrusted end users without a human checkpoint. The failure mode is not a conventional database vulnerability but agent-mediated privilege misuse. As the source material states, "Your database is only as secure as your agent."

Key terminology grounds the discussion. Build-time tools are atomic, flexible constructs - such as NL2SQL execute-SQL tools or control-plane administrative tools - designed for developer assistance and exploratory analytics. Runtime tools are deterministic, parameterized constructs intended for production applications, typically embedded in agent frameworks such as LangChain. The paper proceeds by defining common tool patterns (Section 2), analyzing the divergent requirements of build-time and runtime deployment alongside the threat models that separate them (Section 3), tracing the incremental hardening of a database tool toward zero trust (Section 4), and closing with design trade-offs and broader implications (Sections 5-6).

2. Background and Related Work

The MCP database tooling landscape comprises two complementary deployment models. The MCP Toolbox for Databases is an open-source, self-managed server offering connection pooling, integrated authentication, and observability across more than 40 database systems, with adoption metrics (15.7K stars, 132+ contributors) indicating substantial community consolidation. Google Managed MCP is a fully managed, hosted counterpart pluggable across agent surfaces including Gemini CLI, Anti-gravity CLI, and Cloud Code, incorporating Model Armor for access management and identity control. The combined 20 million monthly tool calls establish that these patterns operate at production scale rather than in prototype settings.

Two threat frameworks inform the security analysis. The confused deputy attack describes a scenario in which a user manipulates an agent into exercising the agent's own elevated privileges on the user's behalf, thereby accessing unauthorized data. The lethal trifecta, coined by Simon Willison, specifies the joint conditions under which such attacks materialize: simultaneous agent access to private data, untrusted content, and an external exposure channel. A representative case cited in the source material involves a malicious insider tricking a triage agent into querying and exposing a salary database - illustrating that the vulnerability lies in tool permission scope, not the underlying database engine.

3. Core Analysis

3.1 Tool Taxonomy: Control Plane, NL2SQL, and Structured SQL

Three tool patterns recur across database-facing agent deployments. Control plane tools support DBA-style operations - creating or managing instances and databases - and require human-in-the-loop review given their destructive potential. NL2SQL tools expose an execute-SQL primitive that lets an agent generate raw SQL dynamically; this flexibility suits exploratory analytics and developer assistance but is unsuitable for unsupervised production use. Structured SQL tools, by contrast, expose predefined, parameterized queries that constrain the agent to fixed logic, preventing SQL injection while also reducing latency and hallucination risk relative to freeform query generation.

3.2 Build Time vs. Runtime as a Security Boundary

The distinction between build-time and runtime is not merely developmental convenience but a security boundary. Build-time tools assume a human observer capable of catching and reversing errors; runtime tools operate without that safeguard against end-user-facing traffic. The source material's demonstration - an agent instructed to delete a table proceeding to do so "fresh" with no safeguards - illustrates the consequence of deploying a build-time tool pattern into a runtime chat scenario. This failure motivates the requirement that production tool design separate three distinct identities: the user identity, the application identity, and the agent identity, and correspondingly separate control over tool inputs into agent parameters (untrusted, dynamic) versus application parameters (trusted, fixed constraints).

3.3 Evolution Toward Zero Trust

The source material traces a staged hardening process. A fully model-controlled tool initially grants the agent superuser-equivalent access to credentials, host, port, connection details, and raw SQL - an insecure baseline. The Toolbox framework introduces a source primitive, which moves connection details out of agent control via a preconfigured YAML file injected at server startup. Read-only restrictions - reported as the top customer request - are enforced down to the database driver level rather than only at the tool-call layer, closing a common bypass vector. Allowed data sets, configured as an enum on the source, restrict blast radius to specific tables or databases. Output size limits function as an additional security layer, preventing the agent or database from being overwhelmed by returned data. Custom tools defined in YAML specify exact SQL statements with customizable names and descriptions, and prepared statements with typed parameters reduce injection risk by validating input types before execution.

The final hardening steps address identity exposure directly. Bounded parameters allow the application to authenticate the user first and bind the resulting parameter directly to the tool, such that the agent never observes the user's identity. Authenticated parameters extend this by having the tool receive and validate a signed JWT or OpenID token, extracting claims (user ID, email, issuer) for binding without agent visibility. Zero trust architecture is achieved when the agent's inputs are limited to simple, non-identifying values such as a date, with all sensitive identifiers resolved outside agent control.

4. Technical Insights

Several implementation-level findings merit direct attention. First, driver-level enforcement of read-only access is materially stronger than tool-level checks, since it removes reliance on correct agent behavior at the query-construction stage. Second, the source primitive pattern generalizes beyond databases: any credential or connection detail that can be resolved at server configuration time rather than agent runtime should be moved out of the agent's parameter space. Third, prepared statements with typed parameters address injection risk at the protocol level, independent of prompt-based mitigations, making them more robust against adversarial input framing.

A trade-off worth noting is between flexibility and safety: NL2SQL tools retain clear value for developer-assisted analytics precisely because their flexibility is paired with human review; removing that review without correspondingly constraining the tool (as in structured SQL patterns) is the identified failure mode, not the flexibility itself. Design-level best practices reinforce this: tools should be built around outcomes rather than atomic REST APIs to reduce round trips and attack surface; descriptions should guide behavior without duplicating parameter documentation; read and write tools should be separated, with reads auto-approved and writes requiring confirmation; errors should be actionable and retryable rather than generic HTTP codes; and inputs should favor flat, simple structures over nested maps, which the source material links directly to increased reliability.

5. Discussion

The findings suggest that agent security for data systems is best understood as a parameter-control problem rather than a purely credential-management problem. Even a database with strong native access controls remains vulnerable if the agent layer can be socially engineered into invoking its own legitimate credentials against unauthorized data - the confused deputy pattern. This reframes security investment: rather than solely hardening the database, teams must harden the tool surface that mediates agent-database interaction.

An open question concerns generalizability beyond relational databases: whether source primitives, bounded parameters, and authenticated-parameter binding transfer cleanly to other stateful systems (file stores, internal APIs, messaging queues) or require pattern-specific adaptation. The scale evidence - 20 million monthly tool calls - indicates these patterns are already load-bearing in production, suggesting that evaluation frameworks such as Eval Bench will become increasingly important for validating that hardened tools preserve functional correctness alongside security guarantees.

6. Conclusion

This synthesis demonstrates that the gap between build-time and runtime tool safety is a design problem addressable through concrete, replicable mechanisms: source primitives, driver-level read-only enforcement, allowed-dataset restriction, prepared statements, and bounded/authenticated parameters. The practical takeaway for engineering teams is that production-facing agent tools must be evaluated not for what they can flexibly accomplish but for what they structurally prevent an agent from being tricked into doing - establishing identity separation and parameter constraint as first-class design requirements rather than afterthoughts.

Sources

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub