The short answer
An AI model cannot reach your database on its own. Something has to connect to it: a connector, an MCP server or a small application that runs queries and returns results. Once that exists, AI tools such as Claude or ChatGPT can answer questions from live data, such as “which projects are over budget this month?”
The real question is how much of the database the AI can reach, and what it can do there.
Two common patterns
1. The AI writes SQL. The connector exposes a “run query” tool. The AI writes the SQL, the connector executes it, and results come back. This is flexible and good for exploration. It is also the riskiest pattern, because the AI can attempt any query the database account allows.
2. The AI calls defined operations. The connector exposes specific, pre-written operations, such as “list overdue invoices for a client” or “get project status”. The AI chooses which operation to call and supplies parameters; it never writes raw SQL. This is less flexible and much easier to reason about.
Many organisations use the second pattern for production systems and reserve the first for analysts working on copies or reporting replicas.
Safety checklist
- Use a dedicated database account. Never connect AI with an administrator or application login.
- Make it read-only. Grant
SELECTonly, unless you have a specific reason not to. - Limit what it can see. Grant access to specific views rather than whole schemas. Views let you remove sensitive columns, such as salaries or personal identifiers.
- Prefer a replica. Point AI at a reporting copy so a heavy query cannot slow down the live system.
- Set limits. Use statement timeouts and row limits to stop runaway queries.
- Log every query. Record the query, who asked for it and which AI ran it.
- Protect the credentials. The connection string should live in the connector, not in a prompt, a chat or an employee’s laptop configuration.
Writing to the database
Letting AI insert, update or delete rows is a different decision. If you allow it, do so through defined operations with validation, not free-form SQL, and consider requiring a person to approve changes that affect money, clients or records other people rely on.
Data that leaves the database
Query results are sent to the AI provider as part of the conversation. If a view contains personal data, that personal data is now being processed by the provider. Under UK GDPR you should understand and document that processing. Design views so the AI receives only what the task needs.
How Kroy approaches it
Kroy connects to databases through Connectors that hold the credentials and define the resources and actions available. Instead of “run any SQL”, an organisation can expose specific, named operations and package them as Skills. Every request is checked against the person, the agent and your policies before Kroy runs it, and every query is recorded. Private systems can use a private Connector that only your organisation sees.