Audit and compliance
Answering “who allowed this” with evidence rather than assurance.
The problem
The question is never whether you have logs. It is whether anybody outside your company can believe them.
Without Bengar
- Application logs held by the audited party.
- Retention policies as the only integrity control.
With Bengar
- Two records: what agents were authorized to do, and what people did to the configuration.
- Append-only storage enforced by the database.
- Merkle batching with roots anchored on a chain.
- Four honest verification outcomes rather than a boolean.
The flow
- Every decision writes an event with its reason.
- Events are batched and the root is anchored.
- Any event can be proven against the anchored root.
- A witness of the reviewer's choosing confirms the root.
Components used
Audit · Proofs · Network
Example
GET /v1/projects/:projectId/audit/:auditId/proof
{ "root": "…", "leaf_version": "…", "path": [ … ], "anchored_height": 128401 }Security properties
- The trail is checkable by somebody who does not trust the Gateway.
- NOT_WITNESSED and UNAVAILABLE are never reported as INVALID.
- A degraded audit write is recorded as degraded, not silently dropped.