Data redaction vs. masking and omission
Data redaction removes or obscures information before it is disclosed. Data masking replaces some or all of a value with a substitute. PII masking applies that treatment to personally identifiable information. Data omission removes a field or element entirely. Products use these labels differently, so check what the recipient will actually see.
NIST's PII confidentiality guidance recommends context-based protection against inappropriate access, use, and disclosure. Before choosing patterns to detect, decide who will receive the data and what they need it for.
These techniques support data minimization: provide only the information needed for the task. They can contribute to data loss prevention, but a particular redaction rule is not a complete DLP program.
Explore Dome: Tool Gateway · Docs: Guards.
Decide what the recipient actually needs
Suppose an agent summarizes support history. It needs case dates and issue categories, but not full phone numbers or payment details.
| Choice | Example result | When to consider it |
|---|---|---|
| Keep | Full issue category | The value is needed for the task |
| Mask | Last few characters of an identifier | Partial recognition is useful and permitted |
| Redact | A replacement marker | The field's existence is useful but its content is not |
| Omit | No field in the result | Neither the field nor value is needed |
| Block | No result delivered | Transformation cannot produce an acceptable result |
For the support summary, omit phone and payment fields if they serve no purpose. Masking is useful when part of a value is still needed. These labels vary between products, so check the actual output.
A masked identifier may still identify someone when combined with case dates or other details. Assess those combinations before treating the result as anonymous.
Explore Dome: Tool Gateway · Docs: Guards.
Decide where the data must be transformed
If the goal is to keep a value out of the model context, the transformation must happen before the model receives it. Redacting the final answer does not erase an earlier disclosure to the model provider.
Likewise, filtering a tool response does not remove copies already written to application logs, traces, or caches. Follow the data from its source to each recipient and identify where the transformation needs to happen.
If sensitive values appear in known fields, a rule can target those fields directly. Free text needs a different inspection strategy because the same information may appear within notes, nested values, or alternate formats.
Dome documents JSON filters for tool arguments and results and text filters for model content. Their configured connection and direction determine which traffic they inspect. Test patterns against representative records to identify information they may miss.
Explore Dome: Model Broker · Docs: Guards.
Test what the recipient actually receives
Build a test record with clearly synthetic values in expected fields, nested structures, arrays, free text, and unexpected fields. Include both values that should change and useful information that should remain.
Inspect the delivered support record: are the sensitive values gone, and are the case dates and issue categories still useful? A log saying the filter ran isn't enough. Repeat the check when the source schema or filter chain changes.
Removing an account identifier that the application requires may leave a misleading or unusable response. Filtering versus validation explains how to check that transformed content still meets the application's requirements.
Use a table to record each field, who needs it and why, and whether to keep, mask, redact, omit, or block it. See AI guardrails for choosing controls beyond data transformation.
Explore Dome: Tool Gateway · Docs: Guards.