Cerbi / Application logging governance
Logging standards. Developer feedback. Runtime governance.
Bring logging standards into everyday engineering with IDE feedback, CI checks, and runtime governance. Give developers useful feedback and give the business shared visibility into how those standards are being applied.
Define. Check. Govern. Improve.
Logging standards / Everyday engineering
Define the context your logs need and the fields they should exclude. Bring required and forbidden logging standards into IDE feedback, CI checks, and runtime governance on supported logging paths.
Application logs continue to your observability and data pipelines. Separately, Cerbi reports governance rules, recorded outcomes, trends, and tagged Relax usage. The normal reporting path excludes application payload; evidence and debug behavior depend on configuration. Relax can allow forbidden fields downstream. Developers, security, data, AI, and leadership teams use the resulting feedback and visibility.
Use findings to identify missing context or forbidden fields, then bring that evidence into your team's review, sprint, or backlog. Engineers and security decide what to change in logging code or policy, test the change, and review the next results.
The loop fits Scrum, Kanban, or your existing workflow. AI assistance can support the team where you use it. Cerbi supplies checks and evidence; your team owns decisions and delivery.
Illustrative source fix: keep service as checkout, add correlationId trace-123, and omit password in the logging code. No real payload or secrets are shown. Consistent fields and required context support debugging, correlation, and downstream analytics. Cerbi supplies checks and evidence; your team owns the decisions, changes, and delivery.
Application logs / Your destinations
Governed application logs continue to your configured observability and data pipelines, including downstream analytics. Consistent structured fields and required context help with debugging, correlation, and analysis.
Governance metadata / Cerbi dashboard
Separately, review rules, recorded outcomes, trends, and Relax usage in Cerbi. This governance reporting path is distinct from your application log destinations. Evidence and coverage depend on the integration, policy, and reporting configuration.
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.
Explore the dashboard01 / 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.
02 / 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.
03 / 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.
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.
How Cerbi works / The governance path
Create a policy, publish it to a target, and apply it at your configured logging integration. Review governance evidence in CerbiShield, then refine your rules.
At your configured
logging integration.
Actions and evidence depend on the integration, policy, and reporting configuration. Verify runtime behavior after publication.
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 intentional developer override using Relax.
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.
