Cerbi / Application logging governance
Sensitive fields. Consistent policy. Evidence of what was governed.
Find unsafe logging, apply policy at selected application or OTLP log boundaries, and retain recorded outcomes. CerbiShield runs in your Azure tenant, beside your existing observability stack.
See it. Control it. Prove it.
Inside CerbiShield / Reporting
See policy outcomes, prioritize application risk, and follow the evidence retained for review.
Inside CerbiShield / From observation to action
A clear view of application risk, recorded policy outcomes and retained evidence. Built to help teams ask better questions of their logging controls.
01 / Reporting
Compare current and prior posture, then explore where blocked, redacted and error outcomes overlap. Turn a broad governance question into a focused review.
Overlap counts application/environment pairs, not event totals. Unknown observations remain unknown; the chart does not imply causality.
02 / Command Center
Bring recorded outcomes, application risk and policy relationships into one review. Give the next investigation a clear starting point.
Review the selected scope and reporting window, then follow a finding into its application context.
03 / Violations Explorer
Move from severity patterns to the application, rule and field behind a finding. Give engineering teams specific evidence to investigate.
Severity, application breakdowns and rule context help narrow the review. Counts retain their own labeled scope and time window.
04 / Evidence Center
Connect governance summaries with retained evidence. Review what is available, its scope, and the source limitations that matter to the decision.
This demo shows a partial Reporting projection. Package inventory and retention sources are unavailable; those states remain visible in the capture.
Your observability platform may already offer processing and redaction. Cerbi is relevant when a logging-control or evidence gap remains: inconsistent policy across teams, sensitive fields escaping controls, or no record of which policy governed a workload. Keep Splunk, Datadog, Azure Monitor, OpenTelemetry, and your existing destinations.
01One logging-governance lifecycle
For platform and security teams facing a customer-assurance or audit deadline: discover unsafe logging, define versioned policy, enforce it at supported boundaries, and prove what happened. Preserve useful debugging context where policy allows.
Discover → Define policy → Enforce → Prove
CerbiShield manages policy versions, rollout, observed coverage, and evidence over time. CerbiStream applies policy in selected applications; Gateway applies it on explicitly configured OTLP log paths. Available actions depend on the integration and policy.
Evaluate CerbiShieldOne governed event, one terminal outcome. Findings are counted separately. Relaxed activity remains traceable.
A policy decision, up close
Inspect the same fictional event before policy, with masking, and with an explicitly permitted relaxation.
Illustrative policy example · synthetic fields.
Not a product screen or live evaluation.
OutcomeRedacted
The configured masking rule protects the email field. Application, operation, and trace context remain useful for debugging.
02Investigation + evidence
Review findings alongside the application, environment, policy version, recorded outcome, and observation window where that context is available. Missing evidence cannot establish control coverage.
Application / Environment / Policy / Outcome / Evidence
See the application risk capture above, or open the complete investigation view in the dashboard tour.
03Reporting + audit
Bring policy outcomes, configuration changes, and authorization history into a reviewable evidence story.
Reporting summarizes observed governance activity. Audit records help explain who changed configuration and when. Deployments and Service Health show the state of the governance plane itself.
Evidence supports governance reviews and audit readiness. It is not certification or a guarantee of regulatory compliance.
Explore reporting and evidence04Governed Applications
Register the application. Authorize the workload. Make access revocable and the lifecycle auditable.
Create a stable, tenant-scoped governed application.
Associate existing Entra workload principals; assign viewer or editor access.
Validate the workload token and active installation entitlement for governed access.
Read back governance profiles and review the recorded lifecycle.
Revoke an assignment or disable the application; authorization fails closed.
Retain the authorization lifecycle, including changes and denials.
Microsoft Entra remains your identity authority. Cerbi validates real workload tokens and tenant-scoped assignments, backed by an active installation entitlement. Revocation and disablement invalidate authorization caches.
Explore workload authorization05AI logging / Pro++ option
AI-related logs can carry sensitive fields too. Apply the same logging-governance lifecycle to supported provider, model, agent, and tool metadata emitted through connected logging paths.
Systems, providers, models, dependencies, and agent/tool context where supported and emitted.
Data classifications, protected-field evidence, request/token metadata, and estimated cost where supplied.
Review recorded runtime outcomes. Raw prompts, responses, and secrets are not collected by default.
Visibility depends on instrumentation and emitted log metadata. This does not authorize agent actions, govern model behavior, or provide universal AI estate coverage.
Customer-hosted architecture
CerbiShield deploys as an Azure Managed Application into the customer’s tenant. Managed identities, server-side tenant isolation, and governed access support architectural control.
Customer tenant
Microsoft Entra
Managed Identity
Azure Managed Application
Customer-controlled infrastructure
Policy, deployment, service health, and evidence in the customer’s operating environment.Build-time signal + runtime evidence
Run the free Scanner independently. Review findings against your existing controls; if a recurring gap remains, evaluate CerbiShield on one workload with an agreed policy and evidence requirement.
A founder-led logging-risk review
Bring a Scanner finding, a sensitive-field concern, or an evidence requirement. Compare existing controls first. If a gap remains, agree one workload, one policy, an evaluation window, and evidence to review before deciding on a recurring CerbiShield deployment.
As AI systems take more actions across enterprise applications, teams need evidence of what happened and how policies were applied. Cerbi helps engineering teams govern application telemetry and review recorded policy outcomes, alongside their existing security and observability tools.
Industry context: OpenAI’s report on the Hugging Face incident and model misalignment.
