Pro edition adds three verification subsystems on top of the community archive: an audit log with a tamper-evident hash chain, scheduled integrity checks over archived content, and compliance verification of export artifacts.
Audit Log
Every security-relevant action is recorded in a dedicated SQLite database (audit/audit.db) with a SHA-256 hash chain: each record stores prev_hash, computed over the previous record's hash, sequence number, and payload. Rewriting or deleting history breaks the chain and is detectable.
Events are written through a bounded background batcher (max 100 records / 500 ms) with an on-disk spill file, so bursts never lose records.
Recorded events include:
user.login,sso.login,ldap.login,mfa.enabled,mfa.disabledemail.viewed,email.deleted,email.batch_deletedemail.exported,export.verifiedlegal.hold.placed,legal.hold.releasedapproval.requested/approved/rejected/executedtimestamp.anchoredintegrity.check_started/completed/cancelledrole.delegated,license.uploaded
The complete list of event types, payload conventions, and which events SIEM forwarding sends is in the Audit Event Catalog.
Retention is unlimited by default (BICHON_AUDIT_RETENTION_DAYS=0). Set a positive number of days to prune older records.
API
| Method | Path | Description |
|---|---|---|
GET | /api/v1/audit-log | Query audit records |
GET | /api/v1/audit-log/export | Export a range as JSON Lines or CSV |
GET | /api/v1/audit-log/{record_id}/detail | Full record detail |
The export keeps each row's raw stored payload, so a third party can recompute the chain digest without trusting the server's re-serialization. The digest rule is SHA-256(prev_hash | seq | payload), joined with | (empty prev_hash for the first record). Ranges are capped at 50,000 records; narrow the range rather than splitting the file.
The WebUI exposes the same data at /audit-log (Enterprise edition; Pro customers use the REST API). Enterprise also adds a one-click evidence pack on the compliance dashboard — a ZIP with the audit range, chain verification, hold cases, retention policy, latest integrity run and timestamp anchors. See Compliance Dashboard.
Integrity Check
A read-only verification that every archived email's stored EML and re-attached attachment blobs still hash to the indexed content_hash — proof that the archive has not rotted or been tampered with.
- Modes:
full(every message) andquick - Scheduling: manual, or automatic every 24 hours by default (
BICHON_INTEGRITY_SCHEDULE_HOURS) - Concurrency: bounded worker pool (
BICHON_INTEGRITY_MAX_CONCURRENCY) - Storage: results in
integrity/integrity.db; reports retained 90 days by default - Reports: summary and per-failure CSV downloads
API
| Method | Path | Description |
|---|---|---|
POST | /api/v1/integrity/run | Start a check (full or quick) |
GET | /api/v1/integrity/jobs/{id}/report/summary.csv | Download summary CSV |
GET | /api/v1/integrity/jobs/{id}/report/failures.csv | Download failures CSV |
Only one integrity run may be active at a time.
Export Verification
Export artifacts record a SHA-256 at completion. Pro adds verification that recomputes the artifact hash and cross-checks every entry against the live archive — messages for an MBOX export, attachment content hashes for a zip export — reporting checked / matched / mismatched counts with mismatch details. The result is recorded as an export.verified audit event.
| Method | Path | Description |
|---|---|---|
POST | /api/v1/exports/{job_id}/verify | Verify a completed export job |
Requires the global data:export:batch:all permission (administrators bypass). The account-scoped data:export:batch permission alone is not enough for verification.
Runtime Configuration
Audit retention, the integrity schedule, and report retention can be changed at runtime from the WebUI (no restart) via GET/POST /api/v1/compliance/config. Runtime overrides take precedence over environment variables and CLI flags.