Selective Log Redaction Overrides for Specific Payloads and Fields

Summary

Moveworks currently applies global log‑redaction rules that often remove sensitive data from all payloads uniformly. While this protects customer information, it can make troubleshooting, debugging, and rule development extremely difficult when certain payloads must be visible temporarily or permanently.

This request proposes a controlled mechanism to disable or override log redaction for specific payloads and specific key/value fields, using an extension to the existing redaction DSL.
 

Problem Statement

Today, log redaction is fairly extreme, and not easily refined at the project level (that I can tell)

• Redaction is applied globally
• Redaction cannot be disabled for specific data objects
• Redaction cannot selectively reveal individual fields
• Debugging issues in pipelines, transformations, audits and DSL logic becomes challenging without visibility into certain parts of the payload

As a result, teams often struggle to analyze issues effectively without temporarily weakening overall log safety.

Proposed Solution: Redaction Override rule

Extend the existing Moveworks redaction rule to support a new structure that allows per‑payload and per‑field exceptions.

{
  "show": {
    "info": [
      "data.anotherPayload.Name.First"
    ],
    "debug": [
      "data.myPayload"
    ]
  },
  "redact": [
    "data.sensitive",
    "data.userPayload.user_choice"
  ]
}

How it would work

1. show list

   • Any paths listed under "show" are preserved in full.
   • Full objects (e.g., data.myPayload) can be whitelisted.
   • Individual fields (e.g., .Name.First) can also be whitelisted.
2. show info/debug 
   • Info or Debug settings mean that item will log in production mode or debug mode.
   • For logging info mode there would be a simple log entry that shows just that payload, this might be similar to accessed_variables in the logs.

3. redact list

   • Specific objects or fields can still be forcibly redacted even if part of a visible payload.

4. Final redaction behavior

   • Redaction system evaluates "show" rules first (explicit allowlist).
   • "redact" takes precedence for any subfields explicitly listed.
   • Any data not mentioned falls back to existing platform defaults.
   • at the kick off a plugin - the redaction rule would show in the logs on the info entry.

Benefits

For Developers

• Can fully inspect problematic payloads during debugging
• Reduces friction and time to resolution
• No need to disable global redaction settings

For Security & Compliance

• Overrides are explicit, documented, and controlled
• Redaction remains applied everywhere except where explicitly allowed
• Still enables field-level protection for sensitive subfield data

For Platform Consistency

• Builds on the existing redaction DSL
• Maintains an opt‑in model rather than broad “disable redaction” switches
• Minimizes implementation complexity while maximizing flexibility