Govern telemetrybefore it spreads.
Across applications and AI systems, 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
CerbiShield product proof
August 2026 release-preview UI
Policy trace
Raw → decision → governed
Raw
user.email
maya.chen@example.com
Governed
REDACT
[REDACTED]
The control boundary
Keep the stack · add the policy
Application
SDK / OTLP
Cerbi policy
Decide · transform
Observability
Existing stack
One governed path,from source to proof.
Four stages sit between a line of code and an auditable record. Nothing is replaced downstream — every stage runs inside what you already operate.
SCANNER-014Console.WriteLine(ssn)Sensitive field logged in plaintext
SCANNER-021npm:experimental-llm-sdkUnpinned AI dependency in production path
SCANNER-007logger.debug(token)Credential-like field detected
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
Show where AI telemetry becomes logging risk.
AI Logging Governance is a Pro++ deployment option that shows named systems, providers, and agents against real telemetry — then connects that activity to policy outcomes and audit evidence.
- Metadata-first — raw prompts and responses stay off by default.
- Customers connect the exact code and telemetry paths they want governed.
- Independent from the Cerbi AI assistant used for rule writing.
Discover
Systems, providers, models, agents, and tools.
Inspect
Requests, tokens, prompts, responses, and sensitive-data exposure.
Govern
Policy decisions, allow / redact / block outcomes, and rule profiles.
Measure
Usage, cost posture, risk trends, and operational telemetry.
Prove
Audit evidence, governance score, environment, remediation context.
Every evidence
packet includes
- Governance score
- Violation evidence
- Rule profile version
- Service + environment
- Remediation context
Raw prompts remain off by default.
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
user.email = "[REDACTED]"authorization = [DROPPED]customer.ip = "[REDACTED]"trace_id = "2f6c0e79d4054b11"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
CERBI003passwordStructured 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.
OTLP workloads
Cerbi Gateway
Existing collector / backend
Observability
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.
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.