Observed AI systems
Review named apps, agents, and tools from connected Cerbi evidence paths.
Flagship: AI Governance
Telemetry security + governance
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
Find risk before deployment
Enforce before the sink
Keep existing destinations
Govern AI systems (Pro++)
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
AI telemetry proof
Show where AI telemetry becomes logging risk.
AI Logging Governance is a separate CerbiShield Pro++ 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.
Cerbi keeps this path metadata-first: scanner evidence, runtime log observations, storage posture, redacted evidence, and raw prompt and response storage off by default. Customers connect the code and telemetry paths they want governed.
Pro++ opt-in. No tenant-wide AI crawl.
Systems & providers
Named AI systems, providers, and models from explicit scanner or runtime evidence.
Agents & tools
Agent and tool signals when they pass through governed telemetry paths.
Requests & tokens
Request and token volume from metadata, without storing raw prompt text by default.
Evidence & policy
Policy outcomes, scanner findings, digests, and review status for audit handoff.
CerbiShield / AI Logging GovernanceCurrent Pro++ product UI
What AI Logging Governance covers
A focused view across connected AI logging paths.
Providers & models
Track provider and model context by service and environment where metadata is present.
Agent and tool context
Surface tool and agent activity when applications emit supported telemetry fields.
Requests and tokens
Show request and token posture from metadata, not retained prompt text.
Estimated cost posture
Estimate usage impact from observed metadata; provider invoices remain authoritative.
Payload exposure
Flag raw prompt, response, RAG context, or tool payload logging risk.
Policy outcomes
Connect AI logging evidence to allow, redact, mask, hash, block, and audit decisions.
Evidence drilldowns
Move from score to rule match, digest, baseline movement, and remediation context.
Evidence packet
Every evidence packet includes
0 governed fields, raw off by default.
- Governance score
- Violation evidence
- Rule profile version
- Service and environment
- Remediation context
The goal is proof of posture without creating a new raw-prompt storage problem.
Customer-hosted
CerbiShield deploys inside the customer's Azure tenant.
Explicit sources
Customers connect the code and telemetry paths they want governed.
Metadata-first
Governance metadata and evidence, not raw content by default.
Raw off by default
Raw prompt and response storage requires explicit customer choice.
Redact before store
Sensitive values are masked, blocked, or summarized before retained evidence.
RBAC and audit
Governance changes, findings, and evidence reviews remain traceable.
Separate AI assistant
AI Logging Governance does not turn on advisory AI assistance.
Aggregate-first
Healthy pass traffic can be summarized; investigation-worthy outcomes stay detailed.
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.2.2CERBI003passwordStructured 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.