Technical architecture
Discover
Scanner finds risk across code and live payloads.
Govern
CerbiShield owns policy, versions, and evidence.
Enforce
Stream or Gateway execute the live boundary.
Cerbi has one policy and evidence model, but it does not force every workload into one runtime topology. Scanner discovers, CerbiShield governs, Stream or Gateway enforces, and CerbiShield retains the operating record.
Architecture
CerbiShield deploys into your Azure environment and governs logging before telemetry reaches your existing observability and security stack. Your data stays under your control.
Cerbi discovers telemetry risk, turns control intent into policy, validates and deploys that policy, enforces it at the right boundary, and keeps the evidence needed to improve the next cycle.
Enforcement is a choice
CerbiStream enforces in-process for selected workloads. Cerbi Gateway enforces at the OTLP boundary for broader coverage with less application integration. Detailed below.
The point of the architecture is not to put Cerbi in every possible place. It is to make the selected policy boundary explicit and govern it consistently.
Architecture rule
Choose the least disruptive boundary that still satisfies the control requirement.
Customer Azure environment
Data plane + customer-hosted governance services
Sources
Selected applications
Logger / Stream path
OTLP workloads
Gateway path
Enforcement choices
CerbiStream
In process
Cerbi Gateway
OTLP boundary
CerbiShield
Policy + targets
Customer storage
Config + evidence
Audit / evidence
Operating record
Control plane
Policy lifecycle and evidence are governed centrally.
Existing destination
Analytics and observability stay where they already are.
CerbiStream
Use Stream when selected applications justify an integration and governance should execute before the first telemetry network hop.
Cerbi Gateway
Use Gateway when existing OpenTelemetry workloads need a lower-friction central adoption path without adding a Cerbi SDK to every emitter.
This real release-preview screen is useful architecture evidence because it ties applications, the Gateway boundary, governance policy, and the existing observability destination into the same operating surface.
See the full Dashboard journey
A redaction rule alone is processing. The governance product is the lifecycle around the rule.
These are more useful than abstract adjectives like “enterprise-ready” because each one can be verified in an evaluation or technical review.
Cerbi is not the search, SIEM, APM, retention, or analytics destination. It governs selected telemetry before it continues to those tools.
CerbiShield centrally owns the governance lifecycle while the execution point can be application-local or at the OTLP boundary.
CerbiShield and Gateway are customer-hosted in Azure. Gateway is not a Cerbi-hosted raw-log relay.
A platform team can choose Stream for selected high-risk applications and Gateway for existing OTLP estates under one governance program.
Scanning, policy, enforcement, routing, deployment, audit, and evidence do not require generative AI to function.
Release state, performance, reliability, and security should be described from tested implementation contracts rather than broad category adjectives.
Architecture review
The right question is not “Can Cerbi replace this stack?” It is “Which boundary gives this workload the control it needs with the least operational disruption?”
Architecture becomes operations
CerbiShield turns the architecture into visible posture: governed activity, policy coverage, enforcement state, workload risk, deployment activity, and the controls that connect those signals.
Use CerbiStream inside selected applications, Cerbi Gateway at the OpenTelemetry boundary, or both. CerbiShield keeps policy, rollout, violations, audit, and evidence under one governance program.