Logging Governance for .NET

Stop sensitive data before it reaches your logs.

Cerbi enforces logging policy inside your application before data reaches Splunk, Datadog, or any downstream system.

  • Prevent PHI, PII, tokens, and credentials from ever being logged
  • Enforce structured logging rules across all services
  • Works with your existing logging stack (Serilog, NLog, MEL)
Microsoft Partner (ISV)
Harvard i-Lab
61.2KNuGet Downloads
Works withMELSerilogNLog

If you're relying on ingest masking, you're already too late.

Real incidents. Same root cause.

Sensitive data was written to logs before any protection was applied.

Credentials captured in logs

Tokens and credentials were captured in internal logs during debugging and support workflows.

Sensitive data was written first and trusted to be masked later.

Cerbi prevents sensitive fields from being logged before it leaves the application.

Passwords written before hashing

User passwords were written to internal logs before hashing completed.

Logging occurred before security controls were applied.

Cerbi enforces logging policy at emission time. Unsafe fields never reach the pipeline.

Session tokens in support artifacts

Session tokens appeared in diagnostic files shared during support workflows.

Sensitive data was collected without restriction at creation time.

Cerbi blocks sensitive fields before they leave the application, not after.

Masking rules missed new formats

Pattern-based masking failed to match new data formats, allowing sensitive values through.

Downstream cleanup depended on incomplete, brittle rules.

Cerbi enforces structured logging policy instead of fragile regex pipelines.

Inconsistent coverage across platforms

Logs were routed to multiple platforms, each with different masking rules and gaps.

Governance existed in some destinations but not others.

Cerbi enforces logging behavior at the source, consistent before it leaves the application.

Source: Common multi-sink architecture pattern

Every incident started with data that shouldn't have been logged.

The distinction that matters

Cleaning up after vs. preventing unsafe logging entirely

Traditional Logging

  • Logs contain raw sensitive data
  • Masking happens downstream
  • Multiple tools, inconsistent rules
  • Audit requires cleanup

Cerbi

  • Logs are compliant at creation
  • Policies enforced automatically
  • One standard across all apps
  • Audit-ready by default

Cerbi does not clean logs after the fact. Cerbi controls what applications are allowed to log in the first place.

Why teams adopt Cerbi

Four problems that source-side governance solves.

Prevent data leakage

Stop sensitive data at the source instead of masking later. PHI, PII, tokens, and credentials are blocked before they ever reach a downstream platform.

Improve audit readiness

Logs are compliant by default, not retroactively fixed. Every log event is governed at creation time, giving you a clean, defensible audit trail.

Reduce observability cost

Filter noise before ingestion. Blocking irrelevant events and redundant fields before they leave the application reduces Splunk and Datadog ingestion spend.

Standardize logging behavior

One policy across all services and teams. Required fields are enforced, schema violations are flagged, and logging behavior is consistent across every service.

How It Works

Logging behavior is governed inside your application, before it leaves the application.

Cerbi intercepts every log event between your framework and the underlying provider. No call-site rewrites. No pipeline replacements. No infrastructure changes.

Application

Your .NET service

Log emitted normally via MEL, Serilog, or NLog.

Governance Layer

Cerbi Governance Layer

In-process, no pipeline changes

Logging policy applied at emission time. Sensitive fields blocked. Schema validated. Violations tagged.

Governed Payload

Only clean, compliant data continues

Redacted fields never enter the pipeline.

Your existing destinations

SplunkDatadogAzure MonitorElasticOpenTelemetrySeq

What happens at each stage

Log emitted normally

Your application code calls _logger.LogInformation() or equivalent. No changes needed to existing call sites.

Logging policy applied in-process

CerbiStream intercepts the event inside the logging provider. Rules from your cerbi.json profile are evaluated at emission time.

Sensitive fields blocked before leaving

Fields matching DisallowedFields are blocked. Fields matching MaskFields are partially redacted. Violations are tagged on the event.

Only governed payload continues downstream

The sanitized log event is forwarded to your existing sinks: Splunk, Datadog, or wherever you send logs today.

Program.cs

builder.Logging.AddCerbiStream();

One line of setup. No changes to existing log call sites. No pipeline migration.

Before vs. after governance

Behavior enforcement before it leaves the application.

Logging policy is applied at emission time, not after data reaches your observability platform.

event.log: before governance
Unprotected
Sensitive data exposed
timestamp: "2024-11-14T09:22:11Z"
message: "User login attempt"
correlationId: "a3f7-c21b"
email: "john.doe@corp.com"PII
password: "abc123!"Credential
ssn: "123-45-6789"PHI
event.log: after governance
Governed
Policy enforced
timestamp: "2024-11-14T09:22:11Z"
message: "User login attempt"
correlationId: "a3f7-c21b"
email: "j***.d***@corp.com"Masked
password: "[REDACTED]"Blocked
ssn: "[BLOCKED]"Blocked

GovernanceViolations

ForbiddenField:password
ForbiddenField:ssn
MaskRequired:email

Logging policy is defined in a JSON profile and enforced at runtime. No pipeline changes, no call-site rewrites.

First hour value

What you will see in the first hour

  • Sensitive fields currently being logged
  • Missing required log fields
  • Logs that violate policy rules
  • Real-time governance violations tagged on events
governed-output.json
Policy enforced
{
  "message": "User login",
  "email": "[REDACTED]",
  "governanceViolations": [
    "SensitiveField: email"
  ]
}

Cerbi tags every governed event with the violations it detected and acted on, giving you an immediate, searchable record of what was blocked or masked.

Platform Overview

One unified governance platform. Three components.

CerbiStream enforces governance in the application. CerbiShield manages it across the platform. CerbiScoring tracks it over time.

CerbiStream

In-app enforcement

The .NET logging provider that enforces governance rules in-process. Blocks sensitive fields, redacts values, and tags violations before any log leaves the application.

Learn more
Management Console

CerbiShield

Governance management and deployment

Central dashboard for managing governance profiles, monitoring violations, and deploying policy updates across environments. Includes RBAC, audit history, and Entra SSO.

Learn more

CerbiScoring

Visibility and posture tracking

Tracks governance health, violation trends, and rule relaxation history across services. Gives security teams a quantified view of logging compliance over time.

Learn more
Who Cerbi is for

Built for engineering organizations running production systems.

Platform Engineering

Standardize telemetry across every service.

  • Enforce consistent log schemas organization-wide without touching existing code
  • Prevent ungoverned telemetry from reaching Splunk, Datadog, or other sinks
  • Policy-as-code that lives in version control alongside your application
Security and Compliance

Stop sensitive data leakage before it happens.

  • Block PHI, PII, credentials, and secrets at the application boundary
  • Immutable, append-only audit trails for SOC 2, HIPAA, and GDPR requirements
  • Full policy change history with actor tracking and approval records
Engineering Leadership

Reduce cost, improve audit readiness.

  • Governance posture visible and measurable across all services and teams
  • Cut ingestion costs by filtering noise and redundant fields before the pipeline
  • Integrate governance validation into CI without blocking developer velocity
Trust and deployment

Designed to be safe for enterprise deployment.

Cerbi is purpose-built for environments where data residency and access controls matter. Your logs stay in your infrastructure, always.

Runs inside your infrastructure

Cerbi is deployed within your tenant. Log payloads, sensitive fields, and governance metadata never leave your environment.

Log data stays in your tenant

No relay servers. No third-party log forwarding. Governance happens in-process. Your observability data stays where it belongs.

Works with your existing observability stack

Sits in front of Splunk, Datadog, Azure Monitor, Elastic, and OpenTelemetry. No pipeline replacement required.

Governance enforced before ingestion

Every log event is validated at emission time, before it leaves the application, not after it reaches a downstream platform.

No pipeline replacement required

Cerbi adds governance without changing how logs flow. Your existing logging infrastructure continues to work unchanged.

Structured, version-controlled policies

Governance rules are JSON files that live in source control alongside your application code. No proprietary config systems.

Most teams secure their systems. Few secure what those systems log.

Stop unsafe logging at the source.

Cerbi enforces logging policy inside your application before data reaches downstream observability platforms. Works with your existing stack. No pipeline changes.

Works with Splunk, Datadog, Azure Monitor, and moreRuns entirely within your infrastructureMicrosoft Partner (ISV)