Masking policies
Create explicit field rules and verify masked output before use.
Masking policies define how sensitive existing values change during data preparation. Open Masking in the sidebar to create or inspect a named policy in the active project.
Choose rules
| Strategy | Intended result |
|---|---|
faker-replace | Substitute a realistic fake value for the detected field class. |
hash | Produce a consistent one-way representation. |
tokenize | Substitute a token, optionally reversible through a key-map token vault. |
redact | Remove the usable value by replacing it with a redaction. |
preserve-format | Produce a fake that passes the supported format's validation. |
Each rule names the field, strategy and, where relevant, its detected class such as EMAIL, IBAN or PERSON_NAME. Consistency and reversibility can be set at policy level and overridden per rule. Only supported tokenization rules are reversible; enabling a policy flag does not make a hash reversible.
Prepare and verify a policy
- Inventory sensitive source fields, including nested values and free text.
- Add explicit rules and check their field names against the data being processed. For a mapping, review the target field names.
- Decide which joins must remain consistent and whether anyone needs authorized reversal.
- Dry-run representative samples, including nulls and unusual formats.
- Inspect uncovered-field warnings, output validity and row counts before using a full result.
The mask data-job path warns about detected sensitive leaves outside the policy but allows unlisted fields through. It is therefore possible for a successful job to retain unlisted source values. Do not treat completion alone as proof that all PII was removed.
Unsupported or unmaskable values can fail a job. Correct the classification or policy and rerun the verification; do not silently copy the refused value into the output.
Consistency and reversal
Consistency depends on project key material, field class and normalized input. Equivalent values classified differently may not map together. Review join behavior on a sample containing related tables.
For reversible tokenization, retain the policy's key-map name and restrict access to the originals. Ordinary Member permissions and READ_WRITE API keys do not include keyMap:reverse. The agent reversal route requires a specific human approval. However, the entries API exposes stored original/token pairs to callers with keyMap:read, so denying only reversal does not hide the originals. See Key maps.
Administrators must preserve the installation's encryption secret across upgrades: changing it affects credential decryption and deterministic masking. See Self-hosted operations.
Evidence
Review the masking run report's processed counts, field counts, policy digest, key fingerprint and warnings. The report is designed to describe the run without embedding raw values. It supports review; it does not certify legal compliance. Keep raw data out of arbitrary logs and exported reports.