Redaction and Masking

Protect sensitive data across document processing, observability, releases, and reviewer workflows.

What This Means in M3 Forge

Redaction and masking in M3 Forge is not a single feature flag. It is a layered privacy pattern that combines:

PII-aware monitoring so prompts, traces, and logs are masked before they are widely visible
Secret-safe administration so environment values and deployment credentials remain hidden in the UI
Retention controls so sensitive operational data does not live longer than necessary
Workflow gates so documents can be reviewed, redacted, or blocked before they are shared downstream

This approach works well when you need strong privacy controls without breaking document automation.

Where It Shows Up

Surface	What it protects
Monitoring	Masks PII in traces and logs before teams inspect request payloads
Releases & Environments	Masks secrets in environment settings and deployment views
Release Gates / Evaluations	Blocks test data, prompts, or outputs that still contain sensitive content
Data Retention	Deletes operational history on a schedule to reduce long-lived exposure
Workflows + HITL	Routes risky documents to review before downstream sharing or export

Example: FOIA or Claims Packet Preparation

Use this pattern when documents need to be shared outside your trusted boundary.

Ingest the source documents

Use a workflow or processor pipeline to classify, extract, and normalize the incoming files.

Detect or flag sensitive content

Apply field extraction, evaluator checks, or custom logic to identify PII such as names, IDs, addresses, or policy numbers.

Route low-confidence cases to review

If the system is not confident that all sensitive values were found, send the document to a reviewer with a HITL correction step.

Mask operational visibility

As teams inspect the workflow in Monitoring, traces and prompts stay masked so support and engineering users do not need raw production PII to debug a run.

Enforce retention

Set retention rules for Monitoring, HITL, and audit data so privacy-sensitive operational history is cleaned up automatically.

Example Workflow Pattern

Example Guardrail Configuration

Use a quality gate to stop outputs that still contain restricted data:


{
  "type": "guardrail",
  "config": {
    "evaluators": [
      {
        "type": "llm_judge",
        "criteria": "Does the output contain unmasked PII or confidential identifiers?",
        "threshold": 1.0
      }
    ],
    "paths": [
      { "path_id": "pass", "target_node_ids": ["share_document"] },
      { "path_id": "fail", "target_node_ids": ["human_redaction_review"] }
    ]
  }
}

For many teams, the strongest immediate privacy win is operational masking: traces, prompts, environment secrets, and review data stay safer even before you add document-specific anonymization workflows.

Good Fits

Sharing claim packets, patient intake packets, or case files with external parties
Debugging LLM workflows without exposing raw customer data to every operator
Enforcing safer release and test practices with PII-aware checks
Reducing stored operational data through category-based retention policies