Find the risk
Scan
Run Cerbi Scanner against source or CI to find unsafe log calls, sensitive-field exposure, schema drift, and governance gaps without changing runtime behavior.
How Cerbi works
Governance is a lifecycle, not a single processor.
Cerbi separates what the organization governs from where the runtime decision executes. That is what lets one governance program support both application-local and OTLP-boundary enforcement.
01The lifecycle
Scan → Govern → Enforce → Prove
Each step answers a different question. Treating them as one black-box “pipeline” hides the operating responsibility the buyer actually has to own.
Make policy explicit
Govern
Use CerbiShield to define the rule, version it, validate it, assign targets, and keep the history behind the control.
Choose the boundary
Enforce
Use CerbiStream inside selected applications or Cerbi Gateway on selected OTLP traffic. The runtime location changes; the governance lifecycle does not.
Keep the operating record
Prove
Review violations, deployment state, audit context, exceptions, and evidence so the control can be explained after rollout.
02One event, two possible enforcement paths
The control question changes the route.
The same policy intent can be enforced closer to the application or at a customer-hosted OTLP boundary. The right choice depends on risk, integration control, and adoption friction.
In-process
CerbiStream
Application → policy decision → downstream telemetry
Use this path when selected applications justify an integration and the governance decision should happen before the first telemetry network hop.
01
Application log call
02
CerbiStream
03
Existing telemetry path
04
Observability
- Closest-to-emission execution
- Application integration required
- Existing logger and destination remain
Customer-hosted OTLP boundary
Cerbi Gateway
OTLP workload → policy decision → downstream telemetry
Use this path when workloads already emit OTLP and platform teams want a customer-hosted central boundary without adding a Cerbi SDK to every application.
01
OTLP workload
02
Cerbi Gateway
03
Existing route / backend
04
Observability
- No Cerbi SDK in OTLP emitter
- Customer-hosted Azure boundary
- Lower-friction estate adoption
03What stays in place
Governance should not require an observability rewrite.
Cerbi is useful when it can be introduced as a control around existing telemetry, not as a demand to replace everything downstream.
Existing logging abstractions
Cerbi does not require teams to replace every logger call or standardize on a new observability backend.
Existing OpenTelemetry
Gateway is designed to sit on selected OTLP paths rather than replacing OpenTelemetry as the telemetry protocol and processing ecosystem.
Existing destinations
Splunk, Datadog, Azure Monitor, Elastic, Sentinel, SIEM, APM, storage, and other downstream tools can remain in place.
Different workload choices
One application can use Stream while another OTLP workload uses Gateway under the same CerbiShield governance program.
04How the control plane fits
CerbiShield sits above the runtime choice.
The Dashboard and governance APIs are where policy, targeting, validation, deployment state, violations, evidence, audit history, and health come together. The runtime boundary is selected below that control plane.
See the product journeyCerbiShield control + evidence plane
Policy / targets / deployment / violations / evidence
CerbiStream
Application process
Cerbi Gateway
Customer OTLP boundary
Existing observability stack
Routing / storage / SIEM / APM / analytics
05A useful first evaluation
Prove the lifecycle on one workload.
The first Cerbi pilot should create a complete evidence chain, not merely show that the platform can be deployed.
Start with one real risk
A repository finding, representative payload, or known OTLP field gives the evaluation a concrete problem.
Define the expected decision
Write down what should be allowed, redacted, dropped, blocked, or otherwise constrained before changing runtime behavior.
Select the least disruptive boundary
Use Stream when application-level integration is justified. Use Gateway where an existing OTLP path is the better adoption point.
Validate before expansion
Confirm policy selection, expected transformation or block behavior, health, and downstream compatibility on the bounded workload.
Review the evidence
End with the policy version, deployment state, finding or violation context, and audit record needed to explain what happened.
No runtime change yet
Start with discovery.
Run the free Scanner against a real repository and use concrete findings to decide whether a runtime governance pilot is justified.
Run ScannerReady for runtime proof
Take one workload through the lifecycle.
Deploy CerbiShield, choose Stream or Gateway, activate one representative control, verify the result, and review the evidence.
Plan a guided pilot