Skip to content

AI

AI Data Masking

When an AI agent queries a database through DBCode, the rows it reads become part of its conversation with the model provider. A routine SELECT * FROM customers can ship real email addresses, card numbers, and social security numbers to the model as a side effect of a legitimate question. Data masking replaces those values before the results leave DBCode, so agents can work with production data without reading the sensitive parts.

Masking applies only to AI agents. Your own queries, grids, and exports always show real data, and DBCode’s own AI features acting on data you can already see are treated as you reading your own data.

Masking is configured per connection, in the connection editor under AI access. It has two parts that work together:

Detectors recognize common sensitive data by inspecting the values a query actually returns, together with column names. The built-in pack covers email addresses, credit card numbers (verified with the Luhn checksum), US social security numbers, phone numbers, IBANs (verified with the ISO checksum), and API keys and other secrets. Because detectors look at the returned values, they catch sensitive data in aliased and computed columns - SELECT ssn AS x is still masked - and in columns whose names give nothing away.

Column rules mask specific columns by name, with * as a wildcard, optionally scoped to a table. Use rules for sensitive columns whose values have no recognizable shape - salaries, free-text medical notes, internal identifiers - and to choose a masking style per column. A rule wins over a detector for the same column, so a rule can also relax a detector’s full mask to a partial one.

Each rule picks a masking style:

StyleExampleBehavior
Full****Replaces the whole value.
Partial (last 4)****6789Keeps the last four characters of text values.
First and lastA****kKeeps the first and last character of text values.
Email (keep domain)a****@example.comKeeps the first character and the domain of email values.

Detectors always mask fully. Partial styles apply to text values; numbers, dates, and other types are always fully masked, short values are fully masked rather than trivially revealed, and nulls stay null.

Masked results tell the agent what happened: the response lists which columns were masked, so the agent does not retry the query to “fix” broken-looking data. Masking follows the data, not the author - when an AI feature writes a query and you run it, you are the one reading the results, so you see real values; only results delivered back to the model itself are masked. If masking cannot be applied safely, DBCode withholds the result entirely rather than returning it unmasked, and errors raised while masking is active are reduced to an error code, with the full text in the DBCode output log - database error messages can quote the very values the mask withheld.

Copying data with the copy data tool follows the same policy. A copy whose source contains masked columns is refused by default, because a bulk copy is either an unmasked export or silently corrupted data. An agent can request the copy anyway with the maskSensitiveData option, which always requires your approval, and then the masked values are what gets written - useful for seeding a development database from production without moving real PII.

Masking reduces accidental exposure. It is not a security boundary, and no client-side masking can be: a determined agent can transform values into shapes no detector recognizes, and database error messages or clever predicates can reveal fragments of what was hidden. DBCode narrows these paths - error details are withheld on masked connections, and detection inspects the actual returned values rather than trusting the query text - but the hard guarantee against an agent reading a table remains denying access with a Blocked or Read-only AI role.

A few practical limits to keep in mind:

  • Detectors match whole values. Sensitive data embedded inside free text or JSON documents is not detected - use a column rule for columns like that.
  • Column rules match by name. When DBCode cannot attribute result columns to their source tables (complex queries, stored procedures), table-scoped rules fall back to matching on the column name alone, which masks more rather than less.
  • The masking configuration is part of the connection’s settings. An agent with write access to your workspace files could edit it there; keep workspace-scoped connections in mind when granting file access to agents.

Masking requires a Pro license. On a lapsed license, agent queries against a connection with masking configured are blocked entirely rather than run unmasked.