A practical pattern for letting AI agents query production data safely by using pre-approved reports as governed tools instead of live SQL generation.
Adapted from @OracleDevs# Would You Let an AI Agent Query Production? Someone asks an agent what discount to offer in APAC next quarter. It thinks for a moment and says 25%. Would you ship that answer? That is the real question when you let an AI agent touch production data. The scary failure is not broken SQL. Broken SQL throws an error. The scary failure is valid SQL that returns a confidently wrong number - and then gets repeated in a pricing deck, forecast, or customer conversation. The hard part is trust, not syntax A model can inspect a schema, find plausible tables, invent a join, and produce a query that runs perfectly. It can also decide that “month” means thirty days since first purchase instead of a calendar month. Ask again tomorrow and it may choose another path. That variability is fine for exploration. It is a rough foundation for a production decision. On the BIRD text-to-SQL benchmark, the best published model reached 80.04% execution accuracy versus 92.96% for humans as reported on August 21, 2026. Leaderboards move, but the architectural point does not: a query can execute successfully and still be wrong. A better pattern: publish the trusted query as a tool Most businesses already have reports that answer the important questions. Their SQL was written, reviewed, debated, and eventually trusted enough to put in front of finance, sales, or operations. So why ask a model to reinvent that logic live? Instead, expose the approved report as a governed MCP tool. Give it a clear name, a description, typed inputs such as quarter, region, and business unit, plus access control. The agent chooses the right tool and fills in the parameters. It never writes the underlying SQL. (https://docs.oracle.com/en-us/iaas/database-tools/doc/database-tools-sql-reports.html?source=:so:tw:or:awr:odv:::Xarticle&SC=:so:tw:or:awr:odv:::Xarticle&pcode=) That changes the agent’s job from “be clever enough to discover the right query” to “be clever enough to select the right report.” Same question, same trusted query path. If the answer changes, the data changed - not the model’s phrasing. Treat the agent like an application - not a superuser The second design problem is identity. An agent should prove who it is before it sees anything. It should act for a person through the corporate identity system and inherit that person’s permissions. No permanent god-mode credential. No silent expansion of access because the request came through a model. Then enforce the policy where the data lives. Row-, column-, and cell-level controls should behave the same whether the caller is a human or an agent. Two employees can ask the same question and get different answers because each sees only what they are cleared to see. This does not make prompt injection disappear. It limits the blast radius when something goes wrong - which is the control your security team actually needs. Don’t forget memory. Agents are stateless unless we give them somewhere durable to keep context. Once that memory contains real company information, it needs the same boring-but-essential protections as the rest of production data: access rules, backups, auditing, and lifecycle controls. In other words, agent memory is not just a prompt-engineering feature. It is a data architecture decision. The production checklist - Keep durable agent memory in a governed data store. - Prefer pre-approved reports or stored query paths for business-critical answers. - Expose those paths as clearly described tools with typed inputs. - Make the agent inherit the requesting user’s identity and permissions. - Enforce row, column, and cell policy in the database, then audit every call. (https://www.oracle.com/security/database-security/features/deep-data-security/?source=:so:tw:or:awr:odv:::Xarticle&SC=:so:tw:or:awr:odv:::Xarticle&pcode=) - Assume prompt injection can happen and design the reachable-data boundary accordingly. There is still a place for natural-language-to-SQL. It is useful for discovery, prototypes, and lower-risk workflows. But for decisions that move money, expose sensitive records, or commit the business to a number, trusted query paths are a much saner default. The production question is not “Can the agent query the database?” It is “Can we explain exactly which path it used, whose permissions it inherited, and what data was reachable?” That is the difference between a cool demo and an agent you can actually ship. Read the full blog to learn more: https://social.ora.cl/6004BG6ybC
