Audit & compliance

Every decision is recorded.

Allowed or denied, every call is written to an append-only audit log with hash chaining, encrypted payloads, and pseudonymized actors. Export, retention, and erasure tooling are part of the product.

The log

What lands in it.

Every decision the gateway makes is a first-class event: which agent called what, the outcome with the reason that produced it, the latency, and the payload in its redacted form. A denial is recorded just as completely as an allow.

The governance workflow is on the same record: approvals and rejections, sync runs with their drift evidence, admin actions, authentication events down to refused identities. An auditor can reconstruct what agents did, and who let them do it.

Actors are stored as keyed pseudonyms, payloads are encrypted per subject, and erasure later destroys the keys instead of rewriting rows.

Audit events page with filters, allow and deny decisions per row, and an expanded event showing actor, scopes, and payload
One row per event, with filters for kind, decision, actor, and time. The expanded row shows actor, scopes, latency, and payload. See it in the console tour →

Tamper evidence

Append-only and verifiable.

Each entry hashes the one before it, so editing or removing a historical entry breaks the chain. Signed checkpoints pin the chain at intervals, and the signing key lives outside the database: rewriting the whole database cannot forge its way past them. Verification runs on every replica, and chain health is a live metric on each pod.

If the database is unreachable, events wait in a crash-safe spool file and are replayed instead of lost. Getting the log out is built in: HMAC-signed webhooks stream events to a SIEM with retry, any filter can be exported as CSV, and OpenTelemetry receives the same reduced form. No export contains more than the log itself stores, and running an export is itself an audited event.

Erasure

Deleting personal data without breaking the chain.

GDPR Article 17 requires deleting a person's data, but the log is append-only. The solution: payloads are encrypted with per-subject keys, and erasure destroys the key. The row stays in place, reads payload_shredded everywhere it is queried, and the hash chain still verifies.

For incidents there is a coarser option that shreds one UTC month for all actors at once. Both operations require sign-off by two people. Retention periods are set by you and enforced by background jobs; the gateway deletes nothing earlier and nothing later than configured.

Erasure has edges. SIEM sinks received earlier exports as plain data, a backup plus the encryption key can undo a shred, and a hard crash can lose the last few events. You are the controller; the gateway supplies the mechanisms and the evidence.

Minimization

Less personal data by default.

IP addresses are left out of the access log unless you turn them on. Tool arguments are stored in the same redacted form that was sent upstream, and DLP runs on audit payloads before they are encrypted.

Reports

Every claim traces to a record.

A per-person report assembles the registry record, sessions, and every ledger event linked through the subject's pseudonyms, live and archived together, for access and portability requests.

The RoPA export is derived from live configuration, never authored: per virtual server, per upstream, per provider endpoint, with safeguards and recipients. Framework packs (GDPR first) map regulation requirements onto a fixed set of checks against the log and the configuration, and grade each one: met, partial, unmet, or operator, where the last one means the product side is done and a documented operator measure, such as processor agreements with your upstreams, closes the gap.

Compliance page with the RoPA panel and a GDPR readiness report listing requirements with evidence
The compliance page: the RoPA panel and the GDPR pack grading each requirement, with the evidence behind every status. See it in the console tour →

See it in your own setup.