Open a database to one team. Do the off-limits tables come along?

#Open a whole database, and the salary table in it opens too

An administrator opens the business database to the sales role. When a sales rep asks for order totals by customer, the AI finds the answer in that database. But if the same database also holds the employee salary table, the customer table is not the only thing now open to sales.

OwlAI on its own can set which databases each role may query: the sales database for the sales team, the HR database for HR. Real company databases are rarely split that neatly, though, and a customer table and a salary table often sit in the same database. Directly connected databases are opened per database, and the boundary inside is set by the privileges of the account used for the connection. With OwlDB, that boundary moves down to individual tables. If an administrator picks only the customer and order tables for the sales role, those two are the only tables the AI can query when a sales rep asks a question.

#With OwlDB, the database enforces the permissions itself

When you connect databases through OwlDB, the administrator does not enter connection details. OwlAI uses the database list OwlDB provides as is, and each role gets its own database account. When an administrator opens a table to a role in OwlAI, that role's database account is granted query privileges on the table; closing the table revokes them. When the AI writes SQL for a sales rep's question, the SQL runs under the sales role's account, and the database rejects any SQL that tries to read the salary table. The database holds this boundary, not the AI.

Scanning the text of AI-written SQL to block table names is not this solid. A view, a table tucked inside a subquery, or engine-specific syntax each opens a path around the check. So OwlAI offers table-level permissions only on connections where the database account can enforce them, and databases connected through OwlDB are exactly that kind of connection.

The boundary has two layers. The AI sees only the tables open to the role from the start and writes SQL against them, and if SQL that touches another table comes out anyway, the database blocks it.

#The audit log shows the role, and the SQL execution history shows the person

If every question runs under one account, the database audit log shows the same account name no matter who asked. A database administrator reading that log cannot tell whether a query came from a sales question or an HR question.

With a separate account per role, the database audit log separates queries by role. Records of individual people live in OwlAI: each time SQL runs, OwlAI records one line saying who sent which SQL to which database, and when (“Asking AI for data you aren't allowed to see: what happens?”). If an auditor asks who queried the salary table last month, you check the role in the database audit log, then find the person and the original SQL in OwlAI's SQL execution history.

#What to check before adoption

If you plan to connect databases through OwlDB, settle these three things first.

• Which tables in the same database need to be opened differently per role
• Who reviews the database audit log for each role
• An audit procedure that reads OwlAI's SQL execution history and the database audit log together