Technical architecture
One governance lifecycle.
More than one enforcement location.
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.
Your tenant.
Your policy.
Your operating record.
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 logs boundary for broader coverage with less application integration. Detailed below.
Find repository and runtime governance gaps on the paths you connect.
Translate control intent into policy and verify representative payloads.
Activate the selected policy at the application or OTLP logs boundary.
Review outcomes, exceptions, and evidence before changing the next policy version.
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.
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.
The Gateway workspace ties applications, the Gateway boundary, governance policy, and the existing observability destination into the same operating surface.
See the full Dashboard journeyA 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 registers tenant-scoped governed applications, validates existing workload tokens and installation entitlement, and enforces viewer/editor assignments. Revocation and disablement invalidate authorization caches and fail closed.
Cerbi is not the search, SIEM, APM, retention, or analytics destination. It governs selected application logs before it continues to those tools.
CerbiShield centrally owns the governance lifecycle while the execution point can be application-local or at the OTLP logs 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 log paths 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?”
Review a Scanner finding or logging requirement against your existing controls. If a recurring gap remains, scope one CerbiShield workload, policy, evaluation window, and evidence review.