Securing Agentic Database Access: Build-Time vs. Run-Time
AI Engineergo watch the original →
the gist
Production agentic systems require moving from flexible, LLM-generated SQL to constrained, pre-defined tools that separate user, application, and agent identities to prevent data breaches.
The Shift from Build-Time to Run-Time
Developer tools for databases fall into two distinct categories. Build-time tools, such as natural language to SQL (NL2SQL) generators and control-plane management utilities, are designed for developer assistance and flexible exploration. These tools require a human-in-the-loop because they are atomic and permissive, often allowing agents to execute arbitrary commands like dropping tables. In contrast, production run-time tools must be deterministic. By using pre-configured, structured SQL with fixed parameters, developers can eliminate SQL injection risks, reduce latency, and prevent agents from hallucinating or executing unauthorized destructive actions.
Securing Agentic Database Access
To prevent the "confused deputy" attack, where an agent is tricked into misusing its privileges to access restricted data, developers must implement a zero-trust architecture that separates user, application, and agent identities.
- Move connection details out of the agent: Use a YAML configuration file to inject database credentials at runtime, ensuring the agent never handles raw connection strings or host details.
- Enforce read-only constraints: Strip write permissions at the database driver level for read-only workflows to minimize the blast radius.
- Implement custom semantic tools: Replace raw SQL generation with custom tools that pin the exact SQL statement behind prepared statements, validating input types to prevent injection.
- Bind sensitive parameters: Use application-level binding or OpenID/JWT tokens to inject sensitive PII (like user IDs) directly into the tool, ensuring the agent never sees or controls the identity data.
- Define output caps: Restrict the volume of data returned by queries to prevent agents from overwhelming the database or leaking large datasets.
- Design for actionable errors: Return specific, actionable error messages rather than generic HTTP codes, allowing the agent to perform intelligent retries or self-correction.