Access Rules

Access rules let owners and admins control which data each role can see. They work alongside RBAC:

• RBAC controls what actions a role can perform (query, recover, manage servers)
• Access rules control which tables and columns are visible within those actions

Concepts

Allow and deny rules

Each rule targets a specific role + schema + table combination and has an effect:

• Allow — grants access to the listed columns
• Deny — blocks access to the listed columns

When both allow and deny rules exist for the same role and table, deny always takes priority. dbtrail warns you about these collisions when creating rules.

Column patterns

Rules specify which columns they apply to using a column list:

To allow all columns except specific ones, create an allow rule with ["*"] and a separate deny rule listing the columns to exclude (e.g., ["ssn", "credit_card"]). The deny rule takes priority, so those columns are stripped while everything else remains visible.

No rules = full access

If a role has no access rules defined, it retains full access to all tables and columns. Access rules are opt-in — adding the first rule for a role begins restricting that role's visibility.

Exempt roles

Owner and admin roles are always exempt from access rules. Only operator, analyst, and viewer can be restricted.

Managing rules via the dashboard

From the dashboard, go to Access Rules (/app/access-rules):

1. Create a rule — select a role, enter the MySQL schema and table name, choose allow or deny, and specify the columns
2. Edit a rule — change which columns are allowed or denied (the role, schema, and table cannot be changed after creation)
3. Delete a rule — remove a rule to restore the role's default access to that table

When you create a rule that conflicts with an existing rule (e.g., an allow rule when a deny rule already exists for the same role and table), the dashboard displays a collision warning explaining the conflict and reminding you that deny takes priority.

Examples

Allow an analyst to see only specific columns

Create an allow rule for the analyst role on mydb.users with columns ["id", "name", "email"]. The analyst can query this table but will only see these three columns — all other columns are stripped from results.

Deny an operator from seeing PII columns

Create a deny rule for the operator role on mydb.customers with columns ["ssn", "credit_card"]. The operator sees all columns except ssn and credit_card, which are stripped from query results.

Block a role from an entire table

Create an allow rule for the operator role on mydb.audit_log with columns ["*"], but do not create any rule for mydb.secrets. Since mydb.secrets is not in the operator's access rules, queries against that table return 403.

How redaction works

Access rules are enforced after the agent returns binlog data — the agent itself has no knowledge of RBAC or access rules. The redaction flow:

1. The agent returns full event data (all columns)
2. The API checks the user's table_access map from their RBAC context
3. The redaction engine strips unauthorized columns from before and after images
4. The client receives only the columns they're allowed to see

Column stripping

For query results, unauthorized columns are removed from the before and after images in each event. Event metadata (timestamp, event type) and the top-level primary_key field are preserved, but primary key columns within before/after are only retained if explicitly listed in the access rule.

Recovery SQL is not column-redacted — the generated SQL contains all columns so it can be executed as-is by a DBA. Recovery enforces table-level access only (403 if blocked).

Forensics SQL removal

When a user has restricted column access, the SQL query text in forensic context is removed. This prevents inferring restricted column values from queries like DELETE FROM orders WHERE ssn = '...'.

Table blocking

If a role has no access rule covering a table, queries against that table return a 403 Forbidden error. The list_tables response also filters out tables the role cannot access.

Collision warnings

When both allow and deny rules exist for the same role and table, dbtrail generates collision warnings. These appear in the API response and in the dashboard UI. The warnings explain which rules conflict and remind you that deny rules always take priority.

For example, if you have:

• Allow analyst on mydb.orders → columns ["*"]
• Deny analyst on mydb.orders → columns ["credit_card"]

The analyst will see all columns except credit_card, because the deny rule takes priority. dbtrail warns about this overlap so you can simplify your rules if desired.