Cerbi / Application logging governance
Control the logs.
Keep the evidence.
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.
Keep the stack.
Add the governance layer.
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
Policy with a
runtime record.
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
Enforce it.
Relax it deliberately.
Keep the evidence.
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
Keep the context.
Change the exposure.
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.
- application
- checkout-example
- operation
- order.created
- customer.email
- [MASKED]
- trace_id
- example-trace-001
OutcomeRedacted
The configured masking rule protects the email field. Application, operation, and trace context remain useful for debugging.
02Investigation + evidence
Follow the finding.
Keep the 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
03Reporting + audit
Governance you
can account for.
Bring policy outcomes, configuration changes, and authorization history into a reviewable evidence story.
Runtime evidence.
Operational context.
A record of change.
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
Identity stays
with Entra.
Control lives with
the workload.
Register the application. Authorize the workload. Make access revocable and the lifecycle auditable.
- 01
Register
Create a stable, tenant-scoped governed application.
- 02
Authorize
Associate existing Entra workload principals; assign viewer or editor access.
- 03
Govern
Validate the workload token and active installation entitlement for governed access.
- 04
Observe
Read back governance profiles and review the recorded lifecycle.
- 05
Revoke
Revoke an assignment or disable the application; authorization fails closed.
- 06
Audit
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
The same controls.
For AI-related logs.
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
Your Azure tenant.
Your operating boundary.
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
Find the gap before it ships.
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
Find the control gap.
Test one workload.
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.