Source-side redaction

Redact sensitive log fields where they originate - inside yourapplication.

Pipeline redaction happens after data has already left your trust boundary. Source-side redaction happens in-process, at the moment the log event is created, before any sink receives it.

The problem

Pipeline-based redaction is structurally too late

Log pipelines - Cribl, Datadog Pipelines, Logstash, Fluentd - receive events after they have already been transmitted from your application. By the time a regex rule scrubs a field, the raw value has already crossed a network boundary, been buffered, and potentially replicated. Source-side redaction is the only approach that prevents data from leaving the application in the first place.

Before and after

Without Cerbi
01
ssn="078-05-1120"PII
02
creditCard="4111-1111-1111-1111"Blocked
03
apiKey="sk-live-xK9mP2..."Secret
04
event="PaymentProcessed"
05
amount="99.00"
With Cerbi
01
ssn="[REDACTED]"PII removed
02
creditCard="[BLOCKED]"Blocked
03
apiKey="[REDACTED]"Secret removed
04
event="PaymentProcessed"
05
amount="99.00"

// Governance runs at emission time, inside the application process. The sink receives only governed output.

Architecture

In-process redaction runs before any network call

CerbiStream is Cerbi's own logging framework with governance built in. Plugin adapters bring the same governance engine to Serilog, MEL, NLog, Java, Go, and Python. When a log event is emitted, governance runs in memory at that moment - before the event is handed to any sink adapter. No event leaves the process in its raw form.

Application code

constructs log event

Logger framework

MEL / Serilog / NLog

CERBI

CerbiStream

redacts at emission time

Log sink

receives clean output only

// Cerbi runs inside your process. No sidecar, no agent, no additional network hop.

Why existing tools are too late

Why pipeline redaction does not solve the problem

Data leaves the application before redaction runs

Pipeline tools receive log events over the network. The raw sensitive value is already outside your application process before any redaction rule executes.

Regex rules miss structural variations

Sensitive data appears in many formats. A regex that matches '078-05-1120' may not match the same SSN formatted differently or embedded in a JSON string. In-process governance can evaluate field names, not just values.

Pipeline redaction adds operational complexity

Every redaction rule in a pipeline is a configuration artefact that must be maintained, tested, and kept in sync with application changes. Source-side governance co-locates rules with application code.

How Cerbi fits with your stack

Drop Cerbi into your existing logging setup

One NuGet, PyPI, Maven, or Go package

Install CerbiStream for your runtime. No infrastructure changes required.

Works alongside pipeline tools

Cerbi governs events before they reach the pipeline. Your Cribl or Logstash config can stay in place for routing and enrichment.

Field-level control

Specify exactly which fields to redact, mask, or block. Rules are evaluated by field name and optionally by value pattern.

CI validation

The Cerbi Scanner ADO extension validates governance profiles against log output shapes at CI time, catching policy violations before they reach production.

Common questions

Frequently asked

Stop sensitive fields in logs at the source

Install CerbiStream in under ten minutes. No infrastructure changes. No pipeline configuration. Governance runs inside your process from the first log event.

// local demo path: install from NuGet, PyPI, Maven, or the Go module registry - no account required

NEXTChoose your next proof

Use CerbiStream inside selected applications, Cerbi Gateway at the OpenTelemetry boundary, or both. CerbiShield keeps policy, rollout, violations, audit, and evidence under one governance program.

One initial workload/Customer-hosted in Azure/Existing destinations remain
Source-Side Log Redaction | Cerbi