Sensitive fields and masking
Understand classification labels and use explicit masking policies for source data.
A sensitive-field classification identifies a field that may contain personal or confidential data. It does not itself prove the values were masked, remove them from arbitrary logs, or block every export.
DataMaker can classify field names through POST /generate/sensitive. The response echoes the supplied fields with a top-level sensitive flag when classification succeeds. An unchanged or absent flag can mean classification failed. Review the result; a name-based classifier cannot establish that a dataset contains no sensitive values.
Generate new data versus mask existing data
A field such as First Name generates a value. An API Response or DB Response field reads an existing source and can return real data. These are different operations even when both appear in the same template.
For existing data, configure a masking policy with explicit rules for each sensitive field. Supported policy strategies are faker-replace, hash, tokenize, redact and preserve-format. The legacy template options sensitive: true and masking: "format-preserve" are not a substitute for that policy.
Review before export
- Identify sensitive columns, nested values and free text in the source.
- Select rules and review whether consistency or reversibility is required.
- Dry-run a small sample and inspect warnings, uncovered fields and output formats.
- Run the policy and review its report before loading or sharing the output.
- Keep raw input and credentials out of scenario logs and chat output.
Unlisted fields can remain unchanged; a partially configured policy is not evidence that all PII was removed. Reversible tokens also retain a route back to originals for authorized users. See Masking policies, Key maps and Approvals.