PII prevention
Control sensitive fields on the logging paths you
connect.
Discover unsafe logging, define versioned policy, and test supported field controls. Retain evidence of governed outcomes without replacing your observability stack. Coverage depends on integration and configuration.
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 applies policy inside selected .NET applications. Dedicated integrations support other logger families and runtimes; their capabilities vary. Gateway provides another boundary for explicitly routed OTLP logs. CerbiShield manages versioned policy, rollout, and recorded evidence.
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
Compare existing controls with the requirement
Identify the required boundary
Existing pipelines can redact sensitive fields. Determine whether application-local control or a configured log boundary meets your requirement, and what evidence confirms it operated.
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. Assess alerting, prevention, and evidence separately; response requirements depend on the incident and your obligations.
Review configured processors
Agents and pipelines may already inspect, transform, or redact content. Test their configuration and coverage before concluding another control is needed.
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. In-process evaluation adds no network hop; measure CPU, allocation, and latency for your policy.
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
Review the logging-control gap
Bring a logging finding or evidence requirement. Compare existing controls, then scope one CerbiShield workload and policy if a recurring gap remains.
// local demo path: install from NuGet, PyPI, Maven, or the Go module registry - no account required