Every change signed, with a copy kept outside the store
Every administrative change is recorded, numbered and signed with a key the store doesn't hold, and copied to your SIEM as it happens. An edit made straight to the store is caught by the server's own check, and the SIEM's copy still shows what was written. A person's runs can be erased on request, and the erasure is recorded by a hash, not a name.
1command checks the store, a file or a SIEM's copy
OpenTelemetry CollectorOTLP logs · acknowledged per batchseq 5
What the auditor runsthe store, then the SIEM's copy
$ queryapigate audit verifyBROKEN at entry 3 (update_key, 2026-10-13 13:22:55): changed$ queryapigate audit verify --file rsyslog.logIntact: entries 1 to 5, keyed with QUERYAPIGATE_AUDIT_KEY.
Stablecompatibility promiseExpmay change in a minor releaseNever kept: the rows a query returns, and parameter values.
AdministratorsWho changed what, and how they signed inA token, a config file from CI, or the shared key. Scoped keys change nothing.
↓
The governed coreRecord → sign → checkEach change numbered, chained to the one before, and signed with a key the store doesn't hold. The server checks the chain every five minutes.
↓
Your storeThe audit log, and run historyAn edit made straight to the store breaks the chain at that entry: audit_chain_broken. Forgetting a person deletes their runs, events and usage counts, recorded by hash, not by name.
↓
Copies outside itYour SIEM, a file, an OpenTelemetry CollectorSyslog over mutual TLS or OTLP logs, each with its own cursor, at least once.
↓
The auditorqueryapigate audit verifyThe store, an export file, or the SIEM's own copy, checked with the same command.
↓
Where data goesRows and parameter values are never keptEvery place data is kept or sent is listed, and a test fails if one is missing.
whothe auditordoorqueryapigate audit verifysigned chain intact ✓SIEM copy verifies too ✓forget by hash, on request ✓dataaudit log · rsyslog.log
For security and compliance teams
Answer the auditor from the running system
An auditor asks who changed which grant, and how you know the record wasn't edited. A questionnaire asks where personal data goes and which cryptography protects it. The answers are the product's own behaviour, each one checkable.
✓Every administrative change in a signed chain, with a copy in your SIEM that verifies on its own. How it works →
✓Where data goes, written down and kept true by a test. history forget erases one person's runs and usage on request, audited by hash, not by name.
# sign the chain, keep a copy, stream it
QUERYAPIGATE_AUDIT_KEY=<a long random key>
QUERYAPIGATE_AUDIT_SYSLOG_URL=tls://siem.example.com:6514
QUERYAPIGATE_AUDIT_SYSLOG_CERT=/etc/queryapigate/client.pem
QUERYAPIGATE_AUDIT_SYSLOG_KEY=/etc/queryapigate/client.key
# the store, and what the SIEM received
queryapigate audit verify
# Intact: entries 1 to 5, keyed with QUERYAPIGATE_AUDIT_KEY.
queryapigate audit verify --file rsyslog.log
# Intact: entries 1 to 5, keyed with QUERYAPIGATE_AUDIT_KEY.
# a data subject asks to be forgotten
queryapigate history forget jwt:alice@example.com --dry-run
The example APIs ship with a generated database and one scoped key per scenario, so you can try each of these in a few minutes without connecting anything of your own.