Data Masking

Data masking transforms sensitive column values in SELECT results before they reach the developer. Masking is column-level and read-side only — writes (INSERT, UPDATE) pass through unaffected. Masking is orthogonal to table grants: a user with SELECT on a table sees masked values for any masked columns, while a user without SELECT cannot query the table at all.

Overview

Masking rules are defined as part of policies. Each rule maps a column match pattern to a masking preset. When a query result includes a matched column, the agent replaces the raw value with a masked version before forwarding it to the client.

• Column-level — masking targets individual columns, not entire rows or tables.
• Read-side only — INSERT and UPDATE statements pass through unaffected. Only SELECT results are masked.
• Transparent — developers see masked values in their query results without any changes to their queries or client code.
• Policy-driven — masking rules are configured in the console as part of a policy and pushed to agents automatically.

Masking Presets

DAAM provides seven built-in masking presets. Each preset is designed for a specific data type and preserves enough structure to confirm the data format while hiding the sensitive content.

Masked values are returned as strings regardless of the original column type.

Adding Masking Rules

Masking rules are configured as part of a policy in the console. To add a masking rule:

1. Navigate to the database and open the policy you want to edit.
2. In the Masking Rules section, click Add Rule.
3. Enter a match pattern (e.g. public.users.email) or use the column dropdown to select from discovered columns.
4. Choose a masking preset from the dropdown.
5. Save the policy.

The column dropdown is populated from the agent's schema introspection. The agent automatically discovers your database's tables and columns and reports them to the control plane, so the dropdown always reflects your actual schema.

Once saved, the updated policy is pushed to the agent immediately. New masking rules take effect on subsequent queries — there is no delay or restart required.

The masking rules editor below shows five rules using different presets. Click a column pattern field to open the searchable dropdown populated from schema introspection data.

Match Patterns

Masking rules use three-part match patterns in the format schema.table.column. Each segment can be a literal name or a wildcard (*). Matching is case-sensitive.

Wildcard patterns let you enforce masking broadly. For example, *.*.email with the email preset ensures that any column named "email" is masked across all tables, including tables added in the future.

Pattern Specificity

When multiple masking rules within a single policy match the same column, more specific patterns override wildcards. For example, public.users.email takes priority over *.*.email when resolving the public.users.email column, while the wildcard still applies to email columns in all other tables.

Strict Masking

By default, masking transforms a column's value in the result set but still allows the column to be used elsewhere in a query — for example in a WHERE clause. That leaves a gap: a determined user could narrow down a masked value indirectly, for instance by filtering on it (WHERE ssn = '123-45-6789') and observing which rows return.

Enabling Strict on a masking rule closes that gap. When a rule is strict, the masked column may only appear in output positions of a query — the SELECT list, ORDER BY, and RETURNING. Any query that references the column where its underlying value could be inferred — WHERE, JOIN conditions, GROUP BY, HAVING, or function arguments — is rejected with an error rather than executed. The developer still sees the masked value in their results; they simply cannot use the column to probe the real one.

Strict is a per-rule option: enable it on the columns where inference is a concern (national IDs, exact salaries, medical codes) and leave it off where ordinary masking is sufficient. Set it with the Strict checkbox when adding or editing a masking rule.

Overlapping Policies

When a user is assigned to multiple policies on the same database and those policies define masking rules for the same column, the most restrictive preset wins. This ensures that sensitive data is never exposed through a less-restrictive policy.

For example, if one policy shows a column unmasked and another redacts it, the column is redacted. The null and redact presets are the most restrictive since they reveal the least information.

If a masking rule exists in one policy but not another, the rule is included in the effective policy. The absence of a masking rule in one policy does not cancel a rule from another.

Most-restrictive-wins applies to a user's standing policies. There is one deliberate exception: an approved access request can temporarily unmask a specific column, overriding a standing mask for the duration of the grant. This lets an admin authorize a narrow, time-boxed exception without weakening the permanent policy. See the Access Requests documentation for details.

Computed Columns and Aliases

Masking works with aliased columns. If you write SELECT email AS e FROM users, DAAM resolves the original column name from the database metadata and applies masking rules that match public.users.email, not the alias.

For computed columns (expressions, aggregates, literals), the agent cannot resolve a physical column identity. Only wildcard rules that match the alias name apply. For example, *.*.cnt would match SELECT COUNT(*) AS cnt, but public.users.cnt would not.

Validation

The following rules are enforced when saving masking rules in a policy:

• Match patterns must have exactly three dot-separated segments (schema.table.column).
• Each segment must be a valid name or the wildcard *.
• The masking type must be a known preset (email, phone, ssn, credit_card, name, redact, or null).
• No duplicate match patterns within the same policy.
• Strict is an optional per-rule flag. When enabled, the column is restricted to output positions only (see Strict Masking above).

Invalid masking rules are rejected on save with an error message indicating which rule failed validation.