How do we build an AI agent that queries our database safely?

A safe database agent starts with a read-only database connection or user role, entirely separate from any write credentials, so that even a malformed or manipulated query cannot alter or delete data. Rather than letting the agent construct arbitrary SQL, expose a small set of parameterized query tools for the specific questions the business actually needs answered, or route free-form requests through a query-generation step followed by a validation layer that checks the generated SQL against an allowlist of tables and columns before execution. Row-level and column-level access controls should mirror whatever restrictions exist for the human users the agent serves on their behalf, so it cannot surface data a given requester would not otherwise be authorized to see, and every query the agent runs should be logged with the requesting user and result size for audit purposes. Setting query timeouts and row limits prevents a runaway query from degrading production database performance, and testing with adversarial prompts that try to trick the agent into broader access is worth doing before launch. For any workflow that eventually needs writes, keep those behind a separate, explicitly permissioned and human-approved tool rather than extending the same read path. Nanobase AI builds these read-only, permissioned database agents as a standard pattern for finance and operations clients.

No single control is sufficient on its own

Teams building their first database agent often reach for one control, usually a read-only database user, and treat that as the safety story complete. A read-only credential is necessary but not sufficient: it prevents data modification while leaving open a runaway query degrading production performance, a query surfacing rows the requesting user should not see, or a poorly constrained text-to-SQL step exposing more data than intended. Database agent safety is a layered architecture, not a single setting.

Parameterized tools beat free-form SQL generation for most use cases

The safest and most predictable pattern is exposing a small set of parameterized query tools for the specific questions the business actually needs answered, such as "look up order status by order ID" or "summarize spend by vendor for a date range," rather than letting the agent construct arbitrary SQL from a natural language request. This trades some flexibility for a query surface that is fully known and reviewable in advance. For genuinely open-ended analytical requests where a fixed set of tools cannot anticipate every question, a text-to-SQL generation step is more appropriate, but it needs a validation layer between generation and execution that checks the generated query against an allowlist of tables and columns before anything runs.

Mirroring existing access controls instead of building new ones

The agent's effective access should never exceed what the human it is acting on behalf of could already see, which means row-level and column-level restrictions need to mirror whatever access control already exists for human users of the same data, rather than being designed as a separate, parallel permission system. Building a new, bespoke access model specifically for the agent risks drift from the actual authorization rules over time, while reusing the existing model, applied per requesting user rather than through one shared service account, keeps the agent's access consistent with policy as that policy evolves.

Building the validation layer step by step

Each of these steps closes a specific gap the others leave open, so skipping one leaves a real hole rather than a minor inconvenience.

1. Define an explicit allowlist of tables and columns the agent may ever query, separate from what the database technically permits the read-only user to see.
2. If using a text-to-SQL generation step, validate the generated query's referenced tables and columns against that allowlist before execution, rejecting anything outside it.
3. Enforce a query timeout and a maximum row count at the database connection level, not just as a suggestion in the generation prompt.
4. Log every executed query with the requesting user, the query itself, and the result row count, retained for audit purposes.
5. Test with adversarial prompts specifically designed to trick the agent into requesting broader access than intended, before granting production access.

Keeping writes on a separate, more guarded path

For any workflow that eventually needs to move beyond read access, the write path should be built as a distinct, explicitly permissioned and human-approved tool set, never as an extension of the same read-only connection or query-generation logic used for lookups. Mixing read and write capability in the same agent path significantly raises the stakes of any flaw in the query validation layer, since a validation gap on a read-only connection risks unwanted data exposure, while the same gap on a connection with write access risks unwanted data modification.

Frequently asked questions

Is a read-only database user enough to make a database agent safe?

No, it prevents data modification but does not prevent overly broad reads, performance-degrading queries, or the agent surfacing data outside the requesting user's actual authorization. It is one necessary layer among several, not a complete safety story by itself.

Should we let the agent generate arbitrary SQL from natural language?

Only with a validation layer that checks generated queries against an allowlist of tables and columns before execution. For most well-defined business questions, a small set of parameterized tools is safer and more predictable than open-ended SQL generation.

How do we prevent the agent from seeing data a specific user shouldn't access?

Apply the same row-level and column-level access controls that already govern what that human user can see through existing applications, scoped per requesting user rather than through one shared, broadly-permissioned database credential for the whole agent.

What should happen when a query exceeds the row limit or timeout?

The query should fail cleanly with a structured error the agent can reason about, such as "result set too large, narrow your date range," rather than either silently truncating results without indication or allowing the query to continue consuming database resources.

How Nanobase AI helps

Nanobase AI builds these read-only, permissioned database agents as a standard pattern for finance and operations clients, layering credential scoping, query validation and access mirroring rather than relying on any single control. This work connects to the broader question of stopping an agent from taking dangerous actions and to EU AI Act and GDPR compliance requirements that often govern what data an agent may access.

Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.