Mask existing sensitive data

Use an explicit masking policy when preparing existing sensitive data for a test environment. A sensitive-field label alone does not mask values or certify that the output is safe to share.

Prepare the pipeline

1. Select a read-only source connection and a small bounded extraction.
2. Inventory sensitive fields and review the intended destination.
3. Create a masking policy covering those fields, with the required consistency and reversibility choices.
4. Dry-run representative data and inspect format failures, uncovered fields and warnings.
5. Run the mask job, review its report and inspect the resulting dataset.
6. Approve the specific load only after the output is ready, then verify delivery.

A useful request to the agent is:

Prepare a plan to extract a small customer sample from our read-only source, mask name, email and date of birth, and deliver it to the staging endpoint. Show the policy and a dry-run report before loading anything.

Verify coverage

Unlisted fields can pass through unchanged, and free-text fields can contain sensitive values not obvious from their names. Review the actual output and warnings. Tokenization with reversal retains access to originals for authorized callers; treat that vault accordingly.

Keep source records out of chat, logs and shared workspace files. A transformation quarantine can also contain original values and needs restricted handling.

Retain evidence

Keep the policy, plan, run IDs, masking report and delivery checks together. These support your team's review; DataMaker completion status is not a legal compliance determination.

See Approvals, Audit and Reconciliation.