Redaction

Every log line, analytics event, and export path in Scrydon flows through a redaction layer. This page documents the patterns it matches and the false-positive cases it deliberately avoids.

Two pattern families

Redaction works on two pattern families: keys and values.

Sensitive keys (suffix-based)

Any object key whose name ends with one of these patterns is redacted:

api_key            access_token       refresh_token
client_secret      private_key        auth_token
*secret            *password          *token
*credential        authorization      bearer

The asterisk patterns match anything containing that word as a suffix. So mySecret matches, password matches, but passwordStrength does not (the sensitive word is a prefix, not a suffix).

Sensitive values (regex-based)

Any string value that matches one of these patterns is redacted regardless of which key it's stored under:

• Bearer tokens — Bearer <opaque token> → Bearer [REDACTED]
• Basic auth — Basic <base64> → Basic [REDACTED]
• API-key prefixes — sk-…, pk-…, api-…, key-… (20+ chars) → [REDACTED]
• JSON credential fields — JSON values for keys matching the sensitive-key pattern → [REDACTED]

Example: object redaction

const input = {
  apiKey: "sk-abc123",
  access_token: "token-value",
  password: "hunter2",
  normalField: "visible",
};
// → { apiKey: "[REDACTED]", access_token: "[REDACTED]", password: "[REDACTED]", normalField: "visible" }

Example: deep nested redaction

The redactor walks nested objects and arrays:

const input = {
  users: [{
    name: "John",                     // ← preserved
    credentials: {
      apiKey: "secret-key",           // ← [REDACTED]
      username: "john_doe",           // ← preserved
    },
  }],
  config: {
    database: {
      password: "db-password",        // ← [REDACTED]
      host: "localhost",              // ← preserved
    },
  },
};

Event sanitisation (keys removed entirely)

For analytics and error reporting, sensitive keys are removed, not masked. This guarantees that a downstream event sink never sees them at all:

sanitizeEventData({
  action: "login",
  apiKey: "secret-key",      // ← removed
  password: "secret-pass",   // ← removed
  userId: "123",             // ← preserved
});

False positives the redactor avoids

Keys where the sensitive word is a prefix (not the full word) are preserved:

This matters in practice — LLM usage events contain tokenCount fields, and a naive redactor that matched any key containing "token" would strip them and break billing.

Where this runs

Redaction is applied at three boundaries:

1. Log emission — every structured log statement passes through the redactor before it's serialised.
2. Analytics events — every event published to the analytics pipeline is sanitised.
3. Workflow export — see Secrets management → Workflow sanitisation on export / share.

Related

• Secrets management — how credentials are stored before they enter the redaction path.
• Audit logging — what gets logged, what's always redacted in metadata.