Cerbi enforces logging policy inside your application, before any log event reaches a pipeline, storage platform, or observability vendor.
CerbiStream is a runtime SDK that governs log events before they reach any downstream sink. CerbiShield is the tenant-hosted control plane for rules, visibility, and audit.
01.How Cerbi fits
Cerbi outputs a normal log.
It just determines what should be logged.
Where Cerbi runs
No changes to your pipeline, ingestion, or dashboards.
Your existing logger, pipeline, and observability tools continue to work as they do today. Cerbi adds control at the source, before the log leaves the application.
Compatible with
By the numbers
Source-side governance
Every log event evaluated before it leaves the application
Pipeline changes required
Cerbi runs in-process. No new infra, no new agents, no migration
To add governance
Drop CerbiStream into your existing logger and start enforcing policy
Frameworks supported
Microsoft.Extensions.Logging, Serilog, and NLog — all natively
02.The Cerbi model
Runtime SDK
Governance Control Plane
Enforcement inline.Scoring and oversight out of band.
Ifyou'rerelyingoningestmasking,you'realreadytoolate.
Cerbi — governance at the source
03.WHY
04. HOW —The pipeline is backwards
Today
With Cerbi
Interactive Demo
Pick a scenario, configure governance rules, and watch what gets sanitized, blocked, and routed asynchronously — before a single byte reaches your observability platform.
{
"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",
}hot path
// Run example to see output
// 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 for .NET.
05.Risk & compliance
PHI, PII, credentials, and tokens written to log sinks become a liability the moment they are ingested — regardless of who controls the destination.
Scrubbing sensitive data from Splunk or Datadog after the fact is operationally expensive and may not satisfy auditors. The log is already stored, indexed, and potentially replicated.
Governance runs at emission time — before any network call, before any sink, before any pipeline. If a rule is violated, it is blocked or sanitized in-process.
Cerbi does not provide legal or compliance advice. Consult your compliance team for regulatory obligations specific to your industry.
06. WILL —Adoption
CerbiStream drops into your existing logging setup. No migration. No new infrastructure on the hot path.
Full setup guideFree trial
14 days · 5M governed events
No credit card required. Full platform access.
View trial detailsInstall-Package CerbiStream.UseCerbi(cfg => cfg.LoadProfile("governance.json"))governance.json → committed, versioned, reviewedNo agents · No pipeline rewrite · No sink replacementWhy teams adopt Cerbi
Stop sensitive data at the source instead of masking later. PHI, PII, tokens, and credentials are blocked before they ever reach a downstream platform.
Logs are compliant by default, not retroactively fixed. Every log event is governed at creation time, giving you a clean, defensible audit trail.
Filter noise before ingestion. Blocking irrelevant events and redundant fields before they leave the application reduces Splunk and Datadog ingestion spend.
One policy across all services and teams. Required fields are enforced, schema violations are flagged, and logging behavior is consistent across every service.
Who this is for
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.
You own the internal developer platform or shared logging infrastructure. You need consistent policy enforcement across many services without mandating call-site rewrites or deploying new pipeline components.
You are responsible for preventing PHI, PII, credentials, and sensitive fields from reaching observability platforms. You need evidence that governance is applied at emission, not retroactively cleaned downstream.
You are designing or auditing logging strategy across a distributed services estate. You want governance that is version-controlled, policy-driven, and compatible with your existing logging framework without lock-in.
Real scenarios
Logging governance failures are not random. They follow recognizable patterns — and each one has a source-side solution.
Healthcare / HIPAA
Situation. A hospital platform logs every auth event, appointment lookup, and API call to Datadog for observability.
Problem. Patient names, MRNs, and diagnosis codes appear in debug fields because developers log full request payloads during development — and it ships to production.
Auth / Token Leakage
Situation. A fintech platform logs authentication events including full request context to help engineers debug token refresh failures.
Problem. Bearer tokens, session IDs, and refresh tokens are included in structured log payloads. Logs flow to Splunk, where they are retained for 90 days and queryable by any engineer.
Compliance / Audit Readiness
Situation. A financial services team faces a SOC 2 audit. Auditors request evidence that sensitive fields are not logged and that logging behavior is consistent across services.
Problem. Logging is implemented differently per team. Some services use structured logs, some use string interpolation. There is no policy document, no enforcement, and no audit trail of what governance exists.
Architecture / Masking Failure
Situation. A platform team implements downstream PII masking inside their Splunk pipeline, treating it as the primary data protection control.
Problem. The masking rule has a regex gap — it handles `email` but not `user_email` or `emailAddress`. The gap goes unnoticed for four months. All three variants reach long-term storage.
07.Voices
CustomerStaff EngineerHealthTech platform, Series BWe were logging auth tokens in error messages for two years before anyone noticed. Cerbi caught it in the first integration test.
FounderFounderCerbiI built Cerbi because every team I worked with had the same problem — sensitive data in logs they didn't know about until it was too late. The fix had to happen at the source.
CustomerEngineering LeadFinTech SaaS, SOC 2 Type IIOur SOC 2 audit prep used to involve manual log sampling. Now we pull the governance report from CerbiShield and hand it to the auditors.
Scope
Clarity on scope is part of a credible product. Cerbi does one thing well: governs logging behavior at the source.
Not a SIEM
Cerbi does not collect, correlate, or alert on security events. It governs what is written to logs at the source. Your SIEM receives cleaner, more consistent data as a result.
Not a log storage platform
Cerbi has no log storage. Your existing destinations — Splunk, Datadog, Azure Monitor, Elastic, Seq — remain unchanged. Cerbi sits before them, not instead of them.
Not a replacement for your observability stack
Cerbi does not replace Datadog, New Relic, Grafana, or any observability vendor. It makes the data those platforms receive more accurate, consistent, and policy-compliant.
Not a log router or transport layer
Cerbi does not proxy or relay log traffic. There are no additional network hops on the hot path. CerbiStream is in-process; CerbiShield is async and out of band.
What it is
[ cerbi ] · Start now
One NuGet package. No pipeline changes. Policy-as-code governance that runs in-process before sensitive data ever reaches Splunk, Datadog, or Azure Monitor.