Put AI on the production database, and security asks three questions

#The questions that come up first

When someone proposes connecting AI to a business database, the DBAs and the security team raise the same three questions. What if the AI deletes data by mistake? What if it runs a heavy query and slows down the production system? What if it pulls up data that should not be visible?

OwlAI answers each question with its own safeguard and adds a log on top, four layers in all. Before any SQL the AI writes reaches the database, it passes a permission check and a read-only check; it then runs only within a time budget, and every execution is recorded as one line.

#The AI only reads data

OwlAI only reads from connected databases, and it holds that line in three layers. The outermost is a check before execution: OwlAI inspects the SQL the AI writes and sends nothing to the database that isn't a query. Inside that, the database itself blocks writes. Where the database supports a read-only mode, the query runs in that mode, so the database rejects any write that slips past the check. If the session cannot be made read-only, the query does not run at all.

The last layer is the connection account. The database connection screen shows, for each engine, the SQL that creates an account with query-only privileges, and recommends connecting with that account. Even if the first two layers were breached, data does not change when the account has no write privileges.

#Heavy queries are cut off at the time budget

Every query carries an execution time budget. When the budget runs out, OwlAI cuts the query off, and a time limit set on the database side as well means that if one side misses it, the other stops it. The number of rows fetched at once is capped too, so the AI cannot pull in a huge result wholesale.

The stop button on an answer also reaches the database. When a user presses it, the cancellation is passed to queries already sent to the database, so a query never stops on screen while it keeps running in the database.

With a database connected through OwlDB, the block comes one step earlier. OwlDB filters out heavy queries before they run and ends any session that uses too many resources while running (“Could one AI query slow down your order screen?”).

#The AI sees only what the person asking may see

Administrators decide which databases each role may query. Each person receives one role, and the AI queries databases only within the role of the person who asked. An attempt to query a database that is not allowed is blocked before it runs.

For databases connected through OwlDB, this boundary can be drawn down to individual tables, and the database itself, not OwlAI, enforces it (“Open a database to one team. Do the off-limits tables come along?”). Once you pick the tables a role may see, the AI working for that role cannot query any table you left out.

#Every query is on the record

Each time the AI runs a SQL statement, one line is recorded. On the SQL executions tab of the Activity log screen, administrators see who sent which SQL to which database and when, how many rows came back, and which tables were read. The log also shows whether the statement ran in chat or in a playbook (a feature that runs recurring work automatically). Attempts blocked by the permission or read-only check are recorded separately as Denied.

Deleting a conversation does not delete this log, and it can be downloaded as CSV for audit evidence. Query result values are not stored in the log, so the log does not become another leak path.

#What IT should check before adoption

Before the connection goes live, there are five things for IT to decide or confirm.

• A dedicated connection account with query-only privileges
• The databases each role may query (down to tables for databases connected through OwlDB)
• A read-only replica to connect instead of the production database
• Encryption in transit (TLS) or an SSH tunnel
• Who reviews the SQL execution history, and how often

A replica isn't something OwlAI requires; it is a recommendation to take load off the production database. Unencrypted connections carry an Unencrypted connection badge in the connection list, so the setting is hard to overlook.