Stop PII from reaching your logs. At thesource.
Most tools find PII after it has already been written. Cerbi intercepts it inside your application, at emission time, before any sink or pipeline sees it. No post-processing. No alert fatigue. No remediation cost.
The problem
PII reaches logs through paths you do not control
Developers log objects. ORMs log request contexts. Frameworks log exceptions. In each case, personal identifiers - email addresses, names, phone numbers, IP addresses - end up embedded in log events that flow to Splunk, Datadog, Azure Monitor, and cloud storage. By the time any downstream tool flags it, the data is already persisted across multiple sinks.
Before and after
// Governance runs at emission time, inside the application process. The sink receives only governed output.
Architecture
Governance runs in-process, before any network call
CerbiStream is Cerbi's own logging framework. Plugin adapters govern Serilog, MEL, NLog, Java, Go, and Python loggers using the same engine. When a log event is emitted, the governance engine evaluates it against your policy profile in memory before the event reaches any sink adapter. Sensitive fields are redacted, blocked, or masked at that point. The governed output is all Splunk or Datadog ever receives.
Your application
emits log event
MEL / Serilog / NLog
logger framework
CerbiStream
in-process PII governance
Splunk / Datadog
receives governed output
Azure Monitor
receives governed output
// Cerbi runs inside your process. No sidecar, no agent, no additional network hop.
Why existing tools are too late
Pipeline and SIEM tools act after the data has moved
Ingestion scrubbing happens too late
Tools like Cribl or Datadog Pipelines process events after they have already left your application. The raw event is transmitted over the network, buffered, and then processed. At that point the data has already crossed your trust boundary.
SIEM alerts notify, they do not prevent
DLP rules and SIEM detections generate alerts after a PII field has been observed in a log stream. The cost of remediation - removing data from indexed stores, notifying affected users - is the same whether you detect it in one minute or one hour.
Log shipping agents do not inspect content
Fluentd, Logstash, and cloud agent sidecars forward log lines as-is. Content inspection requires configuration, regex maintenance, and adds latency to the shipping path.
How Cerbi fits with your stack
Use CerbiStream directly or drop in a plugin adapter for your existing logger
CerbiStream for .NET
Cerbi's own logging framework, with governance, compression, and enrichment built in. One NuGet package, one line of setup.
Plugin adapters for MEL, Serilog, NLog, Java, Go, Python
Govern your existing logger using the same governance engine. Logback, Log4j2, slog, zap, and Python logging are all supported. No routing changes required.
Policy as code
Governance rules live in cerbi_governance.json, checked into your repo. Validated in CI by the Cerbi Scanner ADO extension.
No network calls on the hot path
All evaluation runs in memory inside your process. Governance adds no additional network hops or latency to log emission.
Splunk, Datadog, Azure Monitor still work as-is
Cerbi governs the event before it reaches the sink. Your existing log routing, dashboards, and alerts continue to work.
RBAC and audit history via CerbiShield
The CerbiShield control plane (deployed in your Azure subscription) tracks violations, governance drift, and policy changes over time.
Common questions
Frequently asked
Stop PII leaking into 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