Skip to content

The audit trail

Every decision writes one audit event: the behavior, the verdict, the evidence, the policy bundle hash, the detections, and the correlation IDs. The trail is the source of truth for compliance evidence, incident investigation, and policy replay.

Two mechanisms, applied per organization:

Hash chain. Each event’s hash covers its canonical fields plus the previous event’s hash; chain heads are persisted for fast recovery and concurrent writers are serialized per org. Modify or delete any historical event and every subsequent link breaks.

Hybrid signatures. Every event is dual-signed with a classical + post-quantum scheme — both must verify; keys are rotated and fingerprinted. Public keys are published at GET /api/audit/signing-key so external auditors can verify independently.

Terminal window
curl -H "Authorization: Bearer tp_..." https://tappass.example.com/api/audit/integrity
{
"status": "intact",
"chain_length": 184203,
"current_head": "9f2c…",
"broken_events": []
}

The endpoint recomputes the entire chain from scratch and re-verifies every signature. compromised means tampering or data corruption — with the exact broken links named. Verification requires no trust in the storage layer: given the public key, the math either checks out or it doesn’t.

The trail is queryable along every correlation axis:

Endpoint Question it answers
GET /api/audit filtered search: action, agent, session, task, category, free text
GET /api/audit/session/{id} everything that happened in one session
GET /api/audit/task/{id} one task’s decisions
GET /api/audit/pipeline/{id} one call’s full record
GET /api/audit/_overview KPIs and facets for the dashboard

Verdicts are deterministic, so history is re-computable:

Terminal window
tappass audit replay <event-id> --policy-overrides new-policy.yaml

Replay answers “what would this policy have done?” against real historical traffic — the safe way to validate a stricter policy before activation, and the forensic way to understand an incident after the fact.

  • Retention is configurable (TAPPASS_AUDIT_RETENTION_DAYS, default 365, 0 = forever) and executed on demand via /api/settings/retention.
  • GDPR erasure is cryptographic: a data subject’s PII fields are replaced with signed erasure tombstones and the erasure is recorded as a signed audit event. The chain structure — and therefore the integrity proof — survives erasure.