Cerbi governs log events at the moment they are written - inside your application, before any sink receives them. Stop sensitive data at the source. Enforce stable schemas. Reduce observability waste.
Runtime governance
Cerbi intercepts sensitive fields before the log is written.
No post-processing. No pipeline scrubbing. The interception happens inside the application, at the moment the log event is emitted.
Most observability platforms detect sensitive data after it has already been written. Cerbi stops it at the source, inside the application process, before any sink receives it.
Scope
What Cerbi is not.
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
- A runtime SDK that governs log events before emission
- A governance control plane for policy management and audit
- A source-side filter that reduces ingestion noise and cost
- A compliance tool that enforces schema at the point of creation
Compatibility
Works with your existing stack.
Cerbi sits before your sinks - not instead of them. Your observability stack, alerting rules, and dashboards remain unchanged. What changes is the quality of the data they receive.
Cerbi does not route, proxy, or buffer log traffic. CerbiStream operates in-process at the point of emission. CerbiShield is async and out-of-band. There are no additional hops on your hot path.
Runtime support
Generally available across four runtimes.
Use CerbiStream, Cerbi's own .NET logging framework, or install a plugin adapter that governs your existing logger - Serilog, MEL, NLog, Logback, slog, or Python logging. Same governance engine, same rules, same output.
- Microsoft.Extensions.Logging
- Serilog
- NLog
dotnet add package CerbiStreamAzure-first. Available on Azure Marketplace.
- Logback (SLF4J)
- Log4j2
implementation 'io.cerbi:cerbi-java-governance'- slog
- zap
go get github.com/cerbi/cerbi-go- logging (stdlib)
pip install cerbi-python-logging-governanceNode.js support in progress.
Why teams buy Cerbi
Three outcomes. One decision.
Prevent PII and PHI from reaching logs.
Sensitive fields are governed at write time - inside the application process, before any log event leaves the runtime. Compliance teams get a defensible audit trail. Security teams stop chasing leaked tokens.
3 fields intercepted per event on average
Restore trust in dashboards and alerts.
Inconsistent field names, missing values, and schema drift make dashboards unreliable. Cerbi enforces a stable schema at the source so every log event that reaches Datadog or Splunk is structurally consistent.
Schema enforcement at emission - not at query time
Lower downstream ingest cost.
Most log volume is noise - debug events, high-cardinality fields, and redundant context that teams never query. Cerbi filters at source, reducing the data volume sent to Splunk, Elastic, or any ingest-billed sink.
Reduce ingest volume without changing sinks
Ifyou'rerelyingoningestmasking,you'realreadytoolate.
Cerbi: governance at the source
Research
The breach data is clear.
Credentials and secrets in logs are a top initial access vector.
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
Industry guidance
The logging community agrees on what not to log.
OWASP, Microsoft, AWS, Heroku, and others all publish the same directive: sensitive data must never reach log sinks. Cerbi is the enforcement layer that makes this automatic.
“The following should usually not be recorded directly in the logs: access tokens, authentication passwords, sensitive personal data, and encryption keys.”- OWASP Logging Cheat Sheet
“Perform sanitization on all event data to prevent log injection attacks - including carriage return, line feed, and delimiter characters.”- OWASP Logging Cheat Sheet
“Don't emit sensitive Personal Identifiable Information (PII). Don't emit encryption keys or secrets to your logs.”- Heroku Dev Center - Logging Best Practices
“Application logging is the process of collecting the events generated by your application and recording them in one or more log files. Log data is a critical input for monitoring, diagnostics, security audits, and compliance.”- AWS Prescriptive Guidance - Logging for Application Owners
“Logging providers store logs, except for the Console provider which displays logs. Consider the security implications when logging, as log entries may contain sensitive information that should not reach unauthorized parties.”- Microsoft ASP.NET Core - Logging in .NET
All citations link to original published sources. Cerbi is not affiliated with any cited organization.
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.
All sensitive fields forwarded to Splunk, Datadog, and every downstream sink.
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
// common objection
“Shouldn't you just not log sensitive data in the first place?”
Yes. And also, reality.
Engineers forget. Frameworks log implicitly. ORMs dump request context. A new field gets added to a model and nobody updates the logging filter. The audit says you're clean until the day it matters.
Sink-side masking is too late.
By the time Datadog or Splunk touches it, the data has already left your process, crossed a network, and been written to disk. You're cleaning up after a spill, not preventing one.
Cerbi governs at write time.
Before the log event reaches any sink - before it serializes, before it transmits - Cerbi checks it against your policy and redacts what shouldn't be there. The clean version is all that ever leaves the app.
When a developer genuinely needs to allow something outside the policy - a debug session, an incident trace - Cerbi provides a deliberate Relax() override. That log is tagged and auditable. It does not silently become the new default.
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.
Architecture
How Cerbi works.
Cerbi sits in the logging path before the sink. The application logs normally. Existing observability platforms still receive events. Cerbi governs the event first.
<100ms
overhead
Your application calls the logger normally. No code changes. Cerbi intercepts the event inside the logging provider before anything leaves the process.
Zero call-site rewrites. Works with MEL, Serilog, and NLog.
Automatic
policy enforcement
Rules from your cerbi.json profile are evaluated at emission time. Sensitive fields are blocked or redacted. Schema is validated. Violations are tagged on the event.
In-process - no external service, no pipeline hop, no latency budget.
Clean
to every sink
Only the governed payload continues downstream. Datadog, Splunk, Azure Monitor, and OpenTelemetry receive compliant logs. Violations route async to CerbiShield.
All data governed at the source. Speed holds at any scale.
Data path
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.
Stop log injection and credential exposure at the source.
Application logs are one of the least-governed data surfaces. Secrets, tokens, and PII land in Splunk, Datadog, and ELK because there is no enforcement layer between the application and the log destination.
- Block API keys, bearer tokens, and passwords before emission
- Prevent log injection attacks via field sanitization
- Enforce OWASP-aligned field allowlists at runtime
- Reduce blast radius when downstream stores are breached
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
CerbiShield is live on the Azure Marketplace. Cross-runtime adapters for Python, Java, Node.js, and Go are all generally available. AI-assisted rule creation, validation, and compliance review are in active development.
.NET Governance
Runtime governance for MEL, Serilog, NLog, and CerbiStream with build-time analyzer support.
CerbiShield
Enterprise control plane - policy management, RBAC, scoring, reporting, and Azure Marketplace deployment. Now live.
Cross-Runtime Adapters
Python, Java, Node.js, and Go adapters are live. The same governance model now runs across all major runtime ecosystems.
AI-Assisted Governance
Prompt-based rule creation, automated validation, log event review, and compliance summary generation - metadata-only, admin approval required.
CerbiSense
Governance metadata analysis to identify policy gaps and rule improvement opportunities - with admin approval required.
CerbiShield - AWS Marketplace
Distribution of the CerbiShield control plane via AWS Marketplace for teams running workloads on AWS.
CerbiShield - Google Cloud Marketplace
Distribution of the CerbiShield control plane via Google Cloud Marketplace for teams running workloads on GCP.
.NET Governance
Runtime governance for MEL, Serilog, NLog, and CerbiStream with build-time analyzer support.
CerbiShield
Enterprise control plane - policy management, RBAC, scoring, reporting, and Azure Marketplace deployment. Now live.
Cross-Runtime Adapters
Python, Java, Node.js, and Go adapters are live. The same governance model now runs across all major runtime ecosystems.
AI-Assisted Governance
Prompt-based rule creation, automated validation, log event review, and compliance summary generation - metadata-only, admin approval required.
CerbiSense
Governance metadata analysis to identify policy gaps and rule improvement opportunities - with admin approval required.
CerbiShield - AWS Marketplace
Distribution of the CerbiShield control plane via AWS Marketplace for teams running workloads on AWS.
CerbiShield - Google Cloud Marketplace
Distribution of the CerbiShield control plane via Google Cloud Marketplace for teams running workloads on GCP.
Roadmap items are directional and may change based on customer needs, security review, and release readiness.
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 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 replacementRepeat · Version profiles · Scale governanceGet started
Try Cerbi your way.
Two paths. Both production-ready. Pick the one that fits how your team evaluates.
Start local demo
Run CerbiStream in your application in minutes. No account required. Install the NuGet package, add one line to your logger config, and see governance in action against your own log events.
dotnet add package CerbiStreamDeploy CerbiShield in Azure
Provision CerbiShield from the Azure Marketplace. Connect your policies, set your governance rules, and get a full audit trail for every governed log event across your fleet.
cerbi.cerbishieldproductionWho 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 teams
Reduce sensitive data exposure before logs spread into observability tools, exports, dashboards, and tickets.
Compliance teams
Generate evidence tied to policy versions and governance enforcement. Helps enforce logging controls and support compliance workflows.
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 visibility. Cerbi does not require call-site rewrites.
Use cases
Real Problems Cerbi Solves
Cerbi addresses operational and security risks that surface when logging behavior is left ungoverned.
Sensitive Data Leakage
Prevent passwords, tokens, PHI, and PII from entering logs.
Audit Readiness
Generate evidence faster without hunting through log pipelines.
Logging Consistency
Enforce required fields and logging standards across teams.
Observability Cost Control
Reduce noisy and unnecessary telemetry before it reaches expensive platforms.
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.
