1,284,920,341
Source-side logging governance · .NET · Azure

Cerbi applies logging policy inside the application. Sensitive fields are redacted, violations are tagged, and governance evidence is captured before logs reach any sink.

76.3K+NuGet downloads
29packages
<1mshot-path overhead
in-processzero-egress

Ifyou'rerelyingoningestmasking,you'realreadytoolate.

Cerbi: governance at the source

Bad logs start in code

Bad logs start in code. Cerbi governs them there.

Most tools clean logs after they already exist. Cerbi applies policy while the log event is being created — redacting sensitive fields, tagging violations, and keeping existing sinks working.

Without Cerbi
01event="UserLoginFailed" email="jane@company.com"
02password="SuperSecret123" token="abc123xyz"
03ip="192.168.1.42" userId="usr_8472hx"
04level="ERROR" service="auth-api" ts="2025-01-14T09:41:02Z"
05// No governance record. Data is in Splunk, Datadog, and every sink.

All sensitive fields forwarded to Splunk, Datadog, and every downstream sink.

With Cerbi
01event="UserLoginFailed" email="[REDACTED]"
02password="[BLOCKED]" token="[REDACTED]"
03ip="[MASKED]" userId="[REDACTED]"
04level="ERROR" service="auth-api" ts="2025-01-14T09:41:02Z"
05GovernanceViolations=["SensitiveField:email","SensitiveField:password","SensitiveField:token","SensitiveField:ip"]

Sensitive fields governed at emission. Violations recorded. Nothing sensitive leaves the process.

Govern logging behavior before bad logs are created.

14-day free trial · No credit card · One-line setup

22%

Of breaches involved compromised credentials as the initial access vector

Verizon DBIR 2025

88%

Of basic web application breaches relied on stolen credentials

Verizon DBIR 2025

94 days

Median time to remediate leaked secrets discovered in a repository

Verizon DBIR 2025

How it compares

Every control has a moment of action.

Downstream masking and pipeline processors act after the application has already emitted the event. Cerbi acts earlier, where the log is created.

Capability
Cerbi
Others
Control pointIn-app vs pipeline
Governs log events before emission
Schema enforcement before emission
Requires downstream configuration
Dependency on external systems
Works with existing log sinksNo replacement required
Async violation reporting
Supported
Not supported
Partial / limited

Architecture

Where Cerbi lives in your stack.

Cerbi sits in the logging path before the sink. The application still logs normally. Existing observability platforms still receive events. Cerbi governs the event first.

Application Boundary
Application
Your service or API
Logger
MEL / Serilog / NLog
Cerbi Governance Layer
Rules · Schema · Sensitivity
Control point
Clean Logs
DatadogSplunkAzure MonitorOTel
Async governance path
Violations
field + rule + severity
Async Queue
non-blocking buffer
CerbiShield
Dashboard + audit

Scope

Where Cerbi Fits

Cerbi governs logging behavior at the source, before sensitive data reaches downstream observability tools.

Most organizations already secure systems of record. The gap is application logging. Logs can create a second copy of sensitive data inside tools that were never designed to store regulated payloads.

Cerbi addresses that gap by enforcing policy before logs leave the application. It works alongside your existing code review, CI/CD, security review, and observability stack.

What Cerbi Governs
Application-generated logs
Structured logging fields
Sensitive field redaction and removal
Required metadata enforcement
CI/build-time validation
Runtime governance checks
Policy versioning and audit evidence
What Cerbi Works With
Microsoft.Extensions.Logging
Serilog
NLog
Azure Monitor
Splunk
Datadog
ELK / OpenSearch
Grafana / Loki
Existing CI/CD pipelines
What Cerbi Does Not Replace
Your observability platform
Legal compliance review or formal certification
Enterprise data catalogs or full DLP programs
Primary clinical, financial, or customer data systems
Developer ownership of safe logging practices
Application Code
Cerbi Governance
Sanitized Logs
Observability Tools

Cerbi gives teams a control layer where logging risk starts: inside the application.

Keep Splunk, Datadog, ELK, Azure Monitor, OpenTelemetry, Serilog, NLog, and Microsoft.Extensions.Logging. Cerbi governs what reaches them.

Roadmap

What's next for Cerbi

Cerbi is .NET-first today and expanding into a cross-runtime logging governance platform. The CerbiShield platform is entering release readiness — adapters for Python, Java, Node.js, and Go are underway.

Available TodayAvailable

.NET Governance

Runtime governance for MEL, Serilog, NLog, and CerbiStream with build-time analyzer support.

.NET
Release ReadinessRelease Readiness

CerbiShield

Enterprise control plane — policy management, RBAC, scoring, reporting, and Azure Marketplace packaging.

Early Adapter WorkIn Progress

Cross-Runtime Adapters

Extending the same governance model into Python, Java, Node.js, and Go logging ecosystems.

PythonJavaNode.jsGo
Future IntelligenceExploring

CerbiSense

Governance metadata analysis to identify policy gaps and rule improvement opportunities — with admin approval required.

Roadmap items are directional and may change based on customer needs, security review, and release readiness.

Control point

Every control has a moment of action.

Datadog
fixesafter ingestion
Splunk
masksat ingest
OpenTelemetry
transformsin pipelines
Cerbi
governsat the source
Cerbi

Datadog, Splunk, OpenTelemetry, and pipeline processors help manage data after emission. Cerbi acts earlier — inside the application, before the log event leaves the process.

Interactive Demo

See Cerbi in the Log Path

Pick a scenario, configure governance rules, and watch what gets sanitized, blocked, and routed asynchronously, before a single byte reaches your observability platform.

Mode
Rule Set
Input Log Event
Sensitive Data Leak
{
  "timestamp": "2025-04-12T14:32:11.042Z",
  "level": "Information",
  "message": "Payment processed",
  "correlationId": "ord-8821-xk",
  "userId": "u_4492",
  "ssn": "382-91-0047",
  "cardNumber": "4111-1111-1111-1111",
  "cvv": "392",
  "amount": 149.99,
  "service": "payment-api",
}
Runtime Flow
Application Boundary
Logger
Your App
Cerbi
Governance

hot path

Sanitized Log
Downstream
Splunk / Datadog
Azure Monitor
Downstream Sanitized Log

// Run example to see output

Governance Result

// Governance score, violations, and async routing appear here

This demo runs entirely in-browser. No log data is transmitted. Behavior reflects Cerbi's in-process governance engine.

[ Incident record ]Real-world breaches attributed to log exposure

Real incident patterns

Logs are one of the least governed data surfaces in modern systems.

Recurring patterns

Sensitive data logged as a debugging shortcut
No field-level schema or restrictions
No enforcement of allowed vs forbidden fields
Over-retention of sensitive operational data
Downstream masking relied on instead of prevention
Searchable analytics stores filled with high-risk fields
Internal support and telemetry systems treated as low-risk

Where Cerbi fits

Define what is allowed to be logged
Block sensitive fields before logs leave the app
Enforce governance at the source
Reduce risk in downstream systems
End of incident record

06. WILLAdoption

Start with one service.

Pick one application, one logging framework, and one governance profile. Add Cerbi, run the app, and see which fields would have reached your observability stack.

Full setup guide

Free trial

14 days · 5M governed events

No credit card required. Full platform access.

View trial details
01
Install from NuGetInstall-Package CerbiStream
02
Add one line to your logger.UseCerbi(cfg => cfg.LoadProfile("governance.json"))
03
Store governance profiles as codegovernance.json → committed, versioned, reviewed
04
Ship: nothing else changesNo agents · No pipeline rewrite · No sink replacement
05
Expand to more services once the pattern is proven.Repeat · Version profiles · Scale governance

Who this is for

Built for the teams who own what gets logged.

Cerbi is a fit when logging behavior needs to be a controlled, auditable property of the platform, not a per-team decision made at the call site.

Platform engineering

Standardize logging behavior across services without replacing every sink or mandating call-site rewrites.

Security and compliance

Reduce sensitive data exposure before logs spread into observability tools, exports, dashboards, and tickets. Get evidence that governance was applied at emission.

Architecture leadership

Turn logging from an unmanaged habit into an enforceable, version-controlled enterprise control. Cerbi works with your existing logging framework without lock-in.

Developers

Keep normal logging workflows while gaining safer defaults and governance feedback. Cerbi does not require call-site rewrites.

07.Origin

Built by engineers who lived the problem.

Cerbi was built after seeing the same problem across multiple production systems: PHI already in Splunk, tokens already in CloudWatch, audit trails that collapsed under review. Every team had already shipped the problem before anyone looked. The check was always too late, too manual, or missing entirely.

Logging governance should not be a post-ingest scrubbing task or a quarterly audit finding. It belongs at the moment the log is written, enforced in the same process, on the same thread, before any sink ever sees the data. That is what Cerbi does.

Get started

Change logging behavior before the next bad log ships.

Pick one application that logs sensitive fields. Add Cerbi, apply a governance profile, and see what changes before data reaches your observability stack.

14-day free trial. No credit card required. One-line setup.