Ian On Docs
Admin console

Data access policies

Sort the queries that AI and people send to your databases into allow, deny, or approval required, and return personal-data columns masked.

The Data access screen controls queries against your connected databases, one query at a time. Permissions in Database connections decide "who can use which tables." Here you decide "which queries run as is, which are blocked, and which a person sees first," and "what to mask in the results."

Open it from the Data access policies, PII masking rules, and Query audit log tabs at the top of the Database connections screen. You can also open it from the Query audit log link in Admin → Audit. Only owners and admins use it.

Policy rules

Each rule has one Effect.

  • Allow — runs the query as is.
  • Deny — doesn't run it.
  • Approval required — gets a decision from an owner or admin before it runs. The request goes to Approvals.

In New rule, set the Name, Effect, Priority (lower values run first), Match roles, Allowed tables (comma-separated), and Denied tables (comma-separated), turn on Enabled, and click Save. A new rule applies to all databases, with no time limit.

Rules are evaluated in order, lowest priority number first, and the first rule that matches applies. A query that matches no rule is denied. Two default rules come built in — one that allows reads by owners and admins, and one that allows reads by agents.

New rules apply to people's queries

Rules you create here apply to queries that people send directly. Agents' queries follow the default agent rule. To narrow what an agent can query, set grantees, tables, and blocked columns under Permissions in Database connections.

If some rules might clash, you'll see "N potential rule conflicts detected," along with which rule is evaluated first.

Policy tester

In Policy tester (dry run), enter an SQL query, a Database ID, and a Test role, then click Run test. Without actually running the query, it tells you which rule applies, which tables the query reads, and which tables were denied. Always test after you change rules.

PII masking rules

Columns that hold personal data come back masked in results. Use the buttons next to Quick add: to drop in common patterns such as email, phone number, national ID, address, and card number, or set a Column pattern and Table pattern yourself in New rule (the * wildcard works).

Masking strategy offers five choices.

  • Full mask — hides the whole value, like ****.
  • Partial mask — keeps only a few characters at the start and end (e.g. al*****.com).
  • Hash — turns identical values into the same hash, so you can still group matching values while they stay masked.
  • Replace with NULL — empties the value.
  • Truncate — shows the value only up to a set length (e.g. hel...).

Paste sample JSON into Masking preview and click Preview to compare Original and After masking side by side.

A masked column stays blocked even if a query tries to pull it out under an alias or inside an expression.

Checking the record

For queries that go through the policies, the outcome — allowed, denied, approval pending, or error — and any masked columns are kept in Query audit log. Requests blocked by Database connections permissions are recorded in Admin → Audit. For details, see Audit → Query audit log.

On this page