Build-Time vs. Run-Time Architecture

Developers must distinguish between tools designed for developer assistance (build-time) and those intended for end-user production applications (run-time).

  • Build-Time Tools: These include control-plane management tools and flexible NL2SQL (Natural Language to SQL) interfaces. They are designed for exploration and DBA tasks where a human is in the loop. They are inherently dangerous in production because they allow the agent to generate arbitrary SQL, which can lead to catastrophic outcomes like accidental table deletion.
  • Run-Time Tools: These are designed for production. They utilize structured, deterministic SQL with pre-configured parameters. By restricting the agent to predefined logic, developers eliminate the risk of SQL injection, reduce latency, and minimize hallucinations.

Preventing the Confused Deputy Attack

A database is only as secure as the agent controlling it. The "confused deputy" attack occurs when a malicious actor tricks an agent into using its high-level privileges to access data it shouldn't. To mitigate this, developers must implement a zero-trust architecture:

  • Identity Separation: Clearly distinguish between user, application, and agent identities. The agent should only possess the minimum privileges required for the specific task at hand.
  • Parameter Control: Move sensitive connection details (host, port, credentials) into a secure configuration (e.g., a YAML file) that the agent cannot access or modify.
  • Blast Radius Reduction: Implement read-only restrictions at the driver level, enforce allowed data sets (enums), and cap output sizes to prevent data exfiltration.

Best Practices for Tool Quality

To ensure reliability and security, tool design should follow these principles:

  • Outcome-Oriented Design: Build tools that perform specific actions rather than exposing atomic REST APIs. This reduces round-trips and improves agent context.
  • Custom Semantic Tools: Instead of allowing agents to write raw SQL, define exact SQL statements in the backend. Use prepared statements with typed parameters to ensure input validation.
  • Actionable Errors: Return errors that the agent can actually act upon (e.g., retryable errors) rather than generic HTTP codes.
  • PII Protection: Never pass sensitive user identifiers (PII) directly through the agent. Use bounded parameters or authenticated tokens (like signed JWTs) where the tool validates the user identity internally, keeping sensitive data out of the agent's reach.