Telemetry security + governance

Govern telemetrybefore it spreads.

Cerbi finds risky logging before deployment, then enforces policy inside selected applications or at the OTLP boundary before sensitive data reaches downstream systems. CerbiShield keeps the evidence, and your existing observability stack stays in place.

Built to fit the estate you already have

Find risk before deployment
Enforce before the sink
Keep existing destinations
95.1K+NuGet downloads
30Published packages
AzureMarketplace

CerbiShield product proof

August 2026 release-preview UI

Product preview
CerbiShield Governance Command Center August 2026 release-preview screen

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
REDACT
user.email = "[REDACTED]"
02Secret / authorization
DROP
authorization = [DROPPED]
03Context / customer.ip
REDACT
customer.ip = "[REDACTED]"
04Allowed / trace_id
ALLOW
trace_id = "2f6c0e79d4054b11"
Governed by default · raw only under the reveal

01 / Discover

Find risky logging before it ships.

Cerbi Scanner gives engineering and security teams a read-only view of sensitive fields, credential-like logging, schema problems, and high-cardinality risk before those patterns become runtime telemetry.

No account · no source upload by default · report-only first

Example findings
Scanner 1.1.0
CERBI003password

Structured field is not allowed

CERBI001email

Sensitive data may be written to logs

CARDINALITYsessionId

High-cardinality field may increase ingest cost

02 / Enforce

Stop violations at the earliest practical boundary.

Use in-process enforcement when you control the application, or the Gateway when workloads already emit OTLP. Both use the same governance model without forcing an observability migration.

OTLP boundary

Cerbi Gateway

Product details

For estates already emitting OpenTelemetry.

OTLP workloads route through a customer-hosted governance boundary, then continue to the observability destinations you already use.

01

OTLP workloads

02

Cerbi Gateway

03

Existing collector / backend

04

Observability

No Cerbi SDK in emitting workloadsCustomer-hosted Azure boundaryBest for lower-friction estate adoption
CerbiShield

03 / Operate

Prove which policy was enforced.

CerbiShield keeps policy, targets, rollout state, violations, audit history, and evidence together so security, platform, and audit teams can verify what actually happened. It does not replace the observability destination or warehouse raw logs to prove governance posture.

CerbiShield product proof
Release-preview UI
CerbiShield Governance Command Center release-preview screen

See where control is active and where attention is needed.

04 / Prove

Prove one workload before you expand.

A first evaluation should answer a technical question, not create a transformation program.

01Scan one repositoryFind a real logging risk in code you already own.
02Choose one boundaryUse CerbiStream in-process or Gateway on an existing OTLP path.
03Verify downstreamConfirm the governed event reaches the destination in the expected form.
04Review the evidenceFinish with the policy, rollout, violation, and operating record.