01
Scan
Know what can go wrong.
Find risky logging in repositories before deciding how to enforce policy.
user.email
authorization
card.number
Logging + OpenTelemetry governance
Govern what getslogged.
Cerbi governs risky logging inside the application or at the OTLP boundary, applying policy before sensitive telemetry spreads while keeping the observability stack you already use.
Built to fit the estate you already have
CerbiStream in-process
Gateway at the OTLP boundary
Existing destinations stay
92.8K+NuGet downloads
30Published packages
AzureMarketplace
CerbiShield product proof
August 2026 release-preview UI
Policy trace
Raw → decision → governed
Raw
user.email
maya.chen@example.com
REDACT
Governed
REDACT
[REDACTED]
The control boundary
Keep the stack · add the policy
Application
SDK / OTLP
Cerbi policy
Decide · transform
Observability
Existing stack
Before policy / after policy
See what was there.Move through what Cerbi removed.
The governed record stays visible. Move your pointer across the telemetry and the area beneath it reveals the original value Cerbi saw before policy. Nothing to click or drag.
REDACT
Replace sensitive content
DROP
Remove an unsafe field
ALLOW
Leave safe telemetry alone
Governed telemetryMove to reveal before policy
01PII / user.email
REDACTuser.email = "[REDACTED]"02Secret / authorization
DROPauthorization = [DROPPED]03Context / customer.ip
REDACTcustomer.ip = "[REDACTED]"04Allowed / trace_id
ALLOWtrace_id = "2f6c0e79d4054b11"Governed by default · raw only under the reveal
01Orient
Start with the control problem, not the product names.
Telemetry governance gets confusing when every tool is introduced at once. Cerbi begins with one question: where do you need control?
01 / Before
A log call, structured event, or OTLP payload contains fields you may not want to travel downstream.
02 / Decision
A policy determines what can pass, what must change, and what should be stopped.
03 / After
Your existing observability stack receives the governed event and keeps doing the job it already does.
02Choose a path
Tell the site what is true about your environment.
There is no required progression through Cerbi. Pick the constraint you actually have and the architecture changes with you.
Recommended starting pointNo forced progression
Govern at the telemetry boundary.
Use Cerbi Gateway when existing OpenTelemetry workloads should pass through a customer-hosted governance boundary without adding a Cerbi SDK to each emitting workload.
01
OTLP workloads
02
Cerbi Gateway
03
Governed telemetry
04
Existing destination
Best when adoption friction matters more than in-process enforcement.
Explore Gateway03Understand the model
One governance lifecycle. Two enforcement boundaries.
The product architecture becomes easier when the control lifecycle is separated from the data-processing location.
The durable mental model
Scan → Govern → Enforce → Prove
02
Govern
Make policy explicit.
CerbiShield owns the rules, targets, versions, rollout state, and evidence around the control.
email → REDACT
authorization → DROP
card.number → REDACT
03
Enforce
Choose the right boundary.
Apply policy in-process with CerbiStream or at the OTLP boundary with Cerbi Gateway.
Stream / application
Gateway / OTLP
Same policy model
04
Prove
Retain the operating record.
Review findings, policy versions, deployments, violations, audit history, and evidence after the decision was made.
Policy hash
Deployment target
Evidence record
Choose the enforcement boundary
Same governance program. Different place in the telemetry path.
Controlled preview
Enforce at an existing OTLP boundary.
Gateway lets OTLP-emitting workloads use Cerbi governance without a Cerbi SDK in every application. It stays inside the customer Azure environment and forwards governed telemetry to existing destinations.
- No Cerbi SDK required in OTLP workloads
- Customer-hosted Azure boundary
- Lower-friction estate adoption
01
OTLP workloads
02
Cerbi Gateway
03
Existing collector / backend
04
Observability
04See the product
The Dashboard is not decoration. Each screen should answer a decision.
These are actual August CerbiShield release-preview screens. Empty states remain empty rather than being filled with fabricated customer activity.
What this proves
Coverage, enforcement posture, governed activity, workload risk, and readiness become one operating view.
CerbiShield / OperateRelease preview · Aug 2026
05Compare approaches
Cerbi does not need every alternative to be bad.
A credible architecture page should show what each approach is genuinely good at, then make the governance gap explicit. That is more useful than a feature-checkmark battlecard.
Open the full architecture comparisonWhere it is strong
Receivers, processors, and exporters make the Collector a powerful vendor-neutral place to filter, transform, redact, and route telemetry.
Governance question
It is a processing substrate. Teams still own policy authoring conventions, deployment discipline, evidence, exceptions, investigation workflow, and long-term governance operations.
06Trust the boundary
Show the tenant boundary literally.
Enterprise buyers should not have to infer where raw telemetry, policy, keys, and evidence live. The website should make the customer-hosted boundary visible before the first architecture call.
CerbiShield services and evidence remain in the customer Azure tenant.
Gateway is customer-hosted and forwards to the customer’s existing destinations.
Cerbi is not positioned as a Cerbi-hosted raw-log relay.
AI is optional; core governance does not require it.
Customer Azure tenant
Policy, enforcement, evidence, and customer telemetry path
Workloads
App logs / OTLP
Enforcement
Stream or Gateway
Destinations
Existing observability
CerbiShield
Policy + targets
Customer keys
Signing + storage
Evidence
Violations + audit
Control metadata
Commercial / support interactions can exist outside the customer telemetry path.
Not the architecture
Raw customer logs are not routed through a Cerbi-hosted SaaS relay as the core product model.
07Prove value
A pilot should end with evidence, not a screenshot.
The evaluation path is deliberately bounded. Prove one real control against one real workload and make the result understandable from code or OTLP input through downstream output and evidence.
01
Scan one repository
Find a real logging risk instead of inventing a demo problem.
02
Choose one workload
Keep the first evaluation bounded enough to understand every decision.
03
Select a boundary
Use CerbiStream for an application integration or Gateway for an existing OTLP path.
04
Activate one control
Redact, drop, block, or otherwise govern one representative field or event pattern.
05
Verify the result
Confirm the downstream event, rollout state, violation behavior, and platform health.
06
Review the evidence
End with the record a security, platform, or audit reviewer would actually need.
Choose your next step
Low-friction discovery
Run the free Scanner
Start without changing runtime architecture. Use the findings to decide whether a governance pilot is worth doing.
Scan a repositoryChoose your next step
Production-style evaluation
Plan one governed workload
Choose CerbiStream or Gateway, activate one representative control, verify the downstream result, and review the evidence.
Plan a guided pilot