Securing database tools used by AI agents starts with a rule that's easy to state and often skipped anyway: never give a model the ability to write or execute raw SQL. A tool that accepts a free-form query string and passes it straight to a database is functionally equivalent to giving the model, and anything that can influence the model's output, direct database access with whatever permissions that connection holds. That's a much bigger surface than almost any legitimate use case actually requires, and it turns every prompt injection or reasoning error into a potential injection attack against the database itself.
Replace raw query parameters with structured, narrow operations
Instead of a generic "run this query" tool, expose specific, narrow operations: get a customer's own order history, update a specific field on a specific record type, search within a defined set of fields. Each of these can be implemented with parameterized queries under the hood, and none of them give the model a path to construct arbitrary SQL, which removes an entire category of injection risk by design rather than by validation alone.
Enforce row-level authorization, not just table-level access
A tool that's allowed to query an orders table needs to also restrict which specific rows a given user can actually see, filtering by the requesting user's own identity or tenant at the query level, not trusting that the model will only ask for its own data. Table-level permissions alone leave every row in that table reachable by any authorized caller of the tool.
Limit which columns a tool can return
A tool built to answer "what's my order status" doesn't need to return every column in the underlying row, including internal fields, other linked identifiers, or metadata that has nothing to do with the question being asked. Define the specific columns each tool returns explicitly, rather than returning a full row and trusting downstream logic to filter it appropriately.
Cap result size and query complexity
A tool that can be asked to return an unbounded number of rows, or trigger an expensive, unindexed query, creates both a performance risk and a data exposure risk if a manipulated call requests far more than a legitimate use case would. Set explicit limits on result size and reject queries whose complexity exceeds a reasonable bound for that tool's purpose.
Audit every query with its actual parameters and row count returned
Database tool calls deserve detailed logging specifically because they're one of the most direct paths to bulk data exposure. Record what was queried, by whom, and how many rows came back, so an unusual pattern, a sudden spike in returned rows, a query touching data outside a user's normal scope, is visible after the fact even if it wasn't caught in the moment.
Consider read replicas or dedicated views for agent-facing queries
Pointing agent-facing tools at a dedicated read replica, or a purpose-built view that only exposes the specific fields a tool needs, adds a physical layer of separation between what an agent can reach and what your production database actually contains. Even if a tool's own logic has a gap, the underlying data source it's querying against is already narrower than your full schema, which meaningfully limits the blast radius of a mistake that manages to slip past application-level checks.
Don't let convenience push you back toward generic query tools
There's a recurring temptation to add "just one" flexible query tool alongside the narrow ones, usually to handle an edge case the narrow tools don't cover. Resist this. Every generic query capability added back in undoes the injection protection the narrow, parameterized design was built to provide, and edge cases are better solved by adding one more specific, scoped operation than by reopening a broad path that undermines everything else you've deliberately restricted.
Where TELEON fits
TELEON enforces policy at the tool-call boundary and can apply privacy vault tokenization to sensitive fields before they reach a model's context, reducing exposure even when a database tool call returns more than intended. The audit trail also supports reviewing query patterns and result volumes for database tools that pass through the gateway.
Designing the actual tool schema, parameterized queries, and row and column level restrictions for a specific database is application-layer work that depends on that database's schema and each tool's intended purpose.
A short checklist
- Never expose a tool that accepts raw, free-form SQL from the model.
- Replace generic query tools with narrow, parameterized operations.
- Enforce row-level authorization filtered by the requesting user or tenant.
- Limit which columns each tool can return, rather than returning full rows.
- Cap result size and query complexity explicitly.
- Log every query's parameters and the row count returned.
- Monitor for queries or result volumes that don't match a tool's typical usage.
Database tools carry more risk per call than almost any other category an AI agent might use, simply because databases are usually where the highest concentration of valuable data lives. Treating them with the narrowest possible design, rather than the most flexible one, is the single change that prevents the largest share of realistic incidents in this area.