Orckai
AI Agents for Databases: Giving Models Real Data Without Handing Over the Keys
An agent that can answer from your live order, invoice, and ticket data is one of the highest-value things you can build — and the fastest way to build it is also the one that fails the security review. Here is the design that gets past it.
The question behind the question
“Can our AI answer questions from the database?” sounds like a retrieval problem. It is really an access-control problem wearing a retrieval costume. The model can already write SQL. What you have to decide is what SQL it is permitted to run, against which schema, as which user, and what happens when it is confidently wrong.
Get that decision right and an agent over your operational data is one of the highest-value things you can build: answers about live orders, invoices, tickets, and inventory, in seconds, without anyone opening a reporting tool. Get it wrong and you have handed a probabilistic system a production credential.
Three ways teams connect agents to databases
1. The raw SQL tool
Give the agent a run_sql tool and a connection string. It is the fastest thing to build and the one that fails review. The model composes arbitrary statements, so your entire safety story rests on prompt instructions and hope. Even with a read-only user, an unbounded query against a large table is a production incident, and nothing in the design tells you afterwards which rows were read.
2. Hand-written tools per question
Safer, and much slower. An engineer writes get_open_invoices(customer_id), validates the input, bounds the result, and exposes it. This works well and it is what most careful teams end up doing — until the business asks for the fortieth tool, and the backlog becomes the bottleneck for every new question.
3. Generated, permissioned tools
The middle path: read the schema, generate one named tool per table or endpoint with typed parameters, bounded results, and explicit permissions, and run them behind a server that holds the credentials. You get the coverage of the raw approach with the discipline of the hand-written one. This is what Orckai's MCP server generation does.
Why MCP matters here: the Model Context Protocol gives tools a standard shape, so the same generated server works with any MCP-capable client rather than being locked to one agent framework. The credentials live in the server; the model only ever sees tool names and typed arguments.
What generation actually produces
Point Orckai at a PostgreSQL, MySQL, SQL Server, Oracle, or MariaDB instance — or a REST API — and it introspects the schema and produces a deployable MCP server, packaged as a Docker container on your own network. What comes out:
- One tool per exposed table or endpoint, named for what it does, with typed parameters the model can fill in correctly
- An explicit allow-list — tables you did not publish do not exist as far as the agent is concerned
- Read-only by default, with writes a deliberate, separate decision rather than an accident of permissions
- Bounded results, so a broad question cannot pull a million rows into a context window
- Credentials held server-side — never in a prompt, never in the model's context, never in a workflow definition
- Invocations recorded in execution history and the audit log, with the calling user and organization attached
The step-by-step walkthrough is in creating an MCP server for PostgreSQL.
Design rules worth adopting
Whatever tool you use, these hold. They are the difference between a demonstration and something you would put in front of a customer.
| Rule | Why |
|---|---|
| Read-only unless proven otherwise | A wrong answer is recoverable; a wrong write is an incident. Writes belong in an approved workflow step, not an open tool. |
| Expose views, not base tables | A view is where you drop columns nobody should see, join the lookup tables, and apply the tenant filter once, in SQL, where it cannot be forgotten. |
| Bound every result | Row limits protect the database, the context window, and the bill. An agent that pulls 50,000 rows has failed even if the answer is right. |
| Name tools for intent | Models choose tools by name and description. search_orders_by_customer gets picked correctly far more often than query_tbl_ord_hdr. |
| Give the agent its own database user | Separate credentials mean you can revoke, rate-limit, and audit its access without touching anything else. |
| Pass the user’s identity through | If the answer depends on who is asking, the filter must come from the session, never from something the model was told in a prompt. |
| Log the call, not just the answer | When someone asks what the agent saw, you need the tool invocation and its arguments — the reply alone will not settle it. |
Where the value actually shows up
The pattern earns its keep in the places where a human currently translates a question into a query and pastes the answer into a chat.
- Support with account context — a widget on your portal that answers “where is my order” from the live system instead of a help article, scoped to the signed-in customer
- Internal operations questions — “which shipments are late this week and who owns them” answered from the ERP, without a report request
- Document plus data — combine a knowledge base for policy with a database tool for the customer's actual entitlements, so the answer is both correct and specific
- Scheduled checks — a workflow that queries every morning, summarises the exceptions, and emails whoever needs to act
- Triage before escalation — gather the account state, recent tickets, and billing status into one summary before a human picks the case up
The failure modes to plan for
Two are worth naming because they surprise people. The first is confident joins: a model asked to relate two tables will invent a plausible relationship if the schema does not make the real one obvious. Exposing views with the joins already made removes the opportunity. The second is stale reasoning: an agent that fetched data three turns ago will happily answer from it. Where freshness matters, make the tool call part of the answer, not part of the history — and say so in the system prompt.
Neither is a reason to avoid the pattern. Both are reasons to shape the tools rather than hand over a SQL prompt.
Start narrow. One database, one schema, a handful of views, read-only, one agent, one team. Watch the tool invocations in the execution history for a week. You will learn more about which questions people actually ask in those seven days than in a month of requirements gathering — and the blast radius stays at zero.
Frequently Asked Questions
Is it safe to give an AI agent access to a production database?
It is safe when the agent calls named, bounded, read-only tools rather than composing arbitrary SQL, when credentials live server-side and never enter the model’s context, when it uses its own database user that can be revoked independently, and when every invocation is logged. It is not safe when you hand it a connection string and a run_sql tool.
Which databases can Orckai generate MCP servers for?
PostgreSQL, MySQL, SQL Server, Oracle, and MariaDB, plus REST APIs. Orckai introspects the schema or specification and produces a deployable MCP server as a Docker container, exposing each table or endpoint you select as a named tool with typed parameters.
How is this different from text-to-SQL?
Text-to-SQL asks the model to write a query and then runs it, so correctness and safety both depend on the generation being right every time. The tool approach inverts that: you decide in advance which operations exist, and the model only chooses among them and fills in parameters. Far less freedom, far fewer ways to be wrong.
Can the agent write to the database?
By default, no. Generated tools are read-only, and writes are a separate, deliberate decision. When a write is genuinely needed, the safer pattern is a workflow step that performs a specific, validated operation — optionally with a human approval step in front of it — rather than a general write tool the agent can invoke at will.
How do I stop one customer’s agent from seeing another customer’s rows?
The filter must come from the authenticated session, not from the prompt. In practice that means exposing views that apply the tenant filter in SQL, and passing the caller’s identity through the tool call. Anything that relies on the model having been told to restrict itself will eventually be talked out of it.
Do I need to write any integration code?
No. Generation reads the schema and produces the server, and you choose which tables or endpoints to expose and with what permissions. The work that remains is the design work worth doing anyway — deciding what should be visible and creating views that shape it.