Asking AI for data you aren't allowed to see: what happens?

#A door closed to a person stays closed to the AI

A sales rep who has no access to HR data asks the AI, "What's the average salary increase this year?" If the AI can reach the entire company database, a door that is closed to the person opens through the AI. Security teams watch for exactly this scene when a company brings in AI for work.

In OwlAI, this question cannot reach past the sales rep's own permissions. The AI queries only within the permissions of the person asking, and a blocked attempt is recorded as a refusal. Administrators decide, for each role, which databases can be queried, which document collections can be searched and which connected external services can be used, then assign people to roles. Opening and closing individual tables within the same database works for databases connected through OwlDB (“Open a database to one team. Do the off-limits tables come along?”). Databases and documents outside your permissions never appear in the list for choosing a question's scope, and if the AI tries to query them anyway, the attempt is refused before it runs.

Company databases are read-only. We recommend connecting with an account that has query permission only, and at execution time OwlAI sends a single query statement and rejects write statements. Documents and meetings have boundaries too. A group's document folder is visible only to that group's members, and a meeting is visible only to the person who created it. Not even administrators can open someone else's meeting.

#Every SQL statement leaves a line, refusals included

Each time the AI runs SQL, one line is recorded: when, who, against which database, what SQL was sent, whether the result was success, refusal or failure, how many rows came back and which tables were read. SQL run in chat and SQL run by playbooks (automations in which the AI works through a set sequence of steps) land in one list, and deleting a conversation does not delete these records. The refused lines also show whether anyone, like the sales rep above, asked questions aimed at data outside their permissions.

#Security decisions and admin viewing are recorded as well

Every security decision made while the AI works is recorded: who approved or denied a tool run, which requests expired, whether a request to use data labeled "Internal models only" was refused, whether personal data was masked in an answer or a file, which tools company policy blocked, and whether code execution was refused because an isolated environment could not be set up. Chat and playbooks are recorded the same way.

Admin events such as sign-ins, settings changes and permission changes are recorded too. When an administrator opens another person's SQL execution records, playbook runs or answer feedback, that viewing is itself recorded as a new line. The administrators who look at the records are subject to them as well.

#Questions and answers stay out of the record

The audit log does not contain the content of anyone's questions or answers, and that content does not appear in the admin console. A conversation belongs to the person who had it, so administrators cannot open other people's conversations. SQL execution records hold no question text or result values either, only which SQL read which tables.

There is one exception: rating an answer. A rating carries its conversation with it, and an administrator can open that conversation to see what went wrong. People are told that the conversation goes along before they send a rating. The line is drawn to keep the facts an audit needs without turning the system into a tool for reading work conversations.

#For an audit request, hand over the filtered screen

Records cannot be deleted from the screen, and admin and security events and SQL execution records are kept for three years or more. The SQL executions list can be filtered by user, database connection, result and period, and exported as CSV. When an auditor asks for "everyone who queried the customer table in this period, and their SQL," you hand over the filtered result straight from the screen. Playbook runs keep failed steps and their reasons as well, so you can explain what automated work did the same way.

Before adoption, settle two things with your security team: which databases and document collections each role should open, and which filters you will apply to the SQL executions list when an audit request comes in.