Putting an AI agent in front of an enterprise database, safely

Language-model agents can now write reasonable SQL, which makes "ask the database a question in plain English" tempting for every business team. I built a database-development agent for a Google Gemini hackathon, and the most useful lessons weren't about prompts. They were about the boundary between the agent and the data. An enterprise database holds billing, contracts and customer records; the agent should get exactly as much access as a careful new analyst on day one.

Give the agent its own, minimal identity

Never connect an agent with an application or DBA account. Create a dedicated role, grant it SELECT on a reporting schema only, and set limits at the role level so they apply no matter what SQL is generated.

-- PostgreSQL
CREATE ROLE ai_reader LOGIN PASSWORD '...' NOINHERIT;
GRANT USAGE ON SCHEMA reporting TO ai_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA reporting TO ai_reader;
ALTER ROLE ai_reader SET statement_timeout = '15s';
ALTER ROLE ai_reader SET default_transaction_read_only = on;

In Oracle the equivalent is a separate schema with grants on views only, plus a Resource Manager consumer group to cap CPU and elapsed time.

Expose views, not tables

Raw schemas are full of legacy names, flags and history tables that confuse a model as much as a new hire. A small set of well-named views, each with a comment explaining what it represents, does two jobs: it improves the agent's accuracy, and it decides what the agent can see. Masking happens in the view, so sensitive columns never reach the model at all.

Prefer tools over free-form SQL

For common questions, give the agent parameterised tools (functions it can call) instead of letting it write arbitrary SQL. "Get open contracts for an account" with an account ID parameter is predictable, testable and fast. Keep free-form SQL as a fallback for exploratory questions, and validate it before execution:

• Parse it and reject anything that isn't a single SELECT.
• Reject references to schemas outside the allow-list.
• Wrap it with a row limit, and run EXPLAIN first to refuse plans above a cost threshold.

Log everything, then read the logs

Store the user's question, the generated SQL or tool call, the row count returned and the time taken. This is your audit trail for compliance, and it's also the best dataset you'll have for improving the agent: the questions people really ask, and where the agent got them wrong.

Writes need a human

If the agent proposes changes, such as data fixes, DDL or ticket updates, it should produce a reviewable change (a script, a pull request, a ticket) rather than execute it. The approval step is where segregation of duties lives, and auditors will ask for it.

Test it like any other system

Build an evaluation set of 30 to 50 real questions with known correct answers, and run it whenever the prompt, model or views change. Track accuracy, and track refusals too: an agent that confidently answers questions it can't answer is worse than one that says so.

Designed this way, an agent becomes a genuinely useful front door to the data, and one your security and compliance teams can sign off.