Model metadata
Provider, model, route, workload, and environment context.
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
61.8K+NuGet downloads
29Published 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
Inside CerbiStream
Govern logs at the source,before they become cost or risk.
Four governance stages sit between your code and your existing sink. Only structured, policy-compliant events make it through.
- 01Policy Normalization
- 02Schema Enforcement
- 03Context Enrichment
- 04Destination Control
Coming optional add-on
AI logging evidence without turning on the assistant.
AI Logging Governance is being prepared as a separate CerbiShield deployment option for teams that need visibility into AI-related telemetry risk. It is independent from the Cerbi AI assistant, which remains focused on rule writing, suggestions, explanations, and onboarding.
Metadata-first
Raw prompts and responses stay off by default.
Scanner findings
AI-related logging risks found before runtime adoption.
Governance result
Policy decision, rule match, severity, and review state.
Redacted evidence
Bounded proof with raw prompt and response storage off by default.
Separate from the Cerbi AI assistant
Disabled by default in deployment
Metadata-first evidence model
Not full AI execution governance
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
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.0CERBI003passwordStructured field is not allowed
CERBI001emailSensitive data may be written to logs
CARDINALITYsessionIdHigh-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
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
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
Current product UI
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.