Policies
Make redaction behavior explicit, reviewable, and versioned alongside your application code.
A detector can find a span, but it cannot know your business intent. A support ticket, a medical record, and an internal join key may need different treatment. Policies turn that decision into a named, reviewable contract.
A policy is your contract
Policies decide which fields are inspected, which detector is used, and what replacement strategy is applied. Keep them in git so a change is reviewed like any other security-sensitive change.
name: customer-message
version: 1.0.0
fields:
free_text:
strategy: autoDeID
relex: true
entity_types: [person, email, phone]
customer_id:
strategy: hash
length: 12 Which setting wins?
The HTTP API applies one explicit precedence order. An inline policy wins first; otherwise entity_types selects the detector-backed redaction path; otherwise the configured REDAX_DEFAULT_POLICY applies. If none is selected, the detector uses its direct default behavior. policy and entity_types cannot be combined.
Choose the right strategy
passThroughNo inspection. Use only for fields that are not sensitive.
maskReplace detected spans with a fixed format.
regexFast, deterministic patterns for structured identifiers.
autoDeIDDetector-backed redaction for names and contextual entities.
hashStable keyed replacements for join keys and analytics.
How to introduce a policy safely
- 01Start from the least permissive built-in policy that fits the field.
- 02Add a fixture containing representative, non-production data.
- 03Run the redaction and inspect both the safe text and the spans.
- 04Bump the policy version when behavior changes.
- 05Deploy the policy with the application release so the audit record can be explained later.