Every AI call, data access, and PHI event on HASP is written to a tamper-resistant audit chain. The chain is tamper-resistant at the database layer, tamper-evident at the cryptographic layer, and externally anchored to a third-party timestamping authority — and you can verify all of it independently, without trusting HASP’s application.
How the chain is built
Each audit entry is linked into a per-org hash chain. Three mechanisms harden it:
| Layer | Mechanism | What it defends against |
|---|
| Hash chain | Each sealed entry carries a SHA-256 hash linking it to the previous entry. | Tampering with, or deleting, any entry breaks the chain and is detectable. |
| Database immutability | BEFORE UPDATE and BEFORE DELETE triggers block mutation of integrity-sealed rows at the storage layer. | Application-level or direct-ORM tampering — the trigger fires regardless of how the SQL is issued. |
| External anchoring | A daily job submits the latest chain hash for each org to an RFC 3161 Timestamping Authority. | A superuser who rewrites the database — the anchored timestamp proves the chain’s prior state existed. |
Writes are serialized per org (advisory lock + transaction) so concurrent writes cannot fork the chain, and verification streams the chain in bounded memory so it scales to 7+ years of activity.
Signed, independently verifiable exports
Audit exports are cryptographically signed with Ed25519 for non-repudiation. A signed export contains:
| File | Purpose |
|---|
audit-log.csv | The full audit trail, including integrity-hash columns. |
manifest.json | Metadata, the CSV’s SHA-256 hash, the chain-verification result, and the Ed25519 public key. |
manifest.sig | A detached Ed25519 signature over manifest.json. |
Verification is self-contained: confirm the signature against the published public key, confirm the CSV hash matches the manifest, and confirm the manifest reports a valid chain.
Verify it yourself with @usehasp/verify
HASP publishes an open-source verifier that checks a signed export end-to-end — hash chain continuity, Ed25519 signatures, and the RFC 3161 TSA timestamps — entirely on your machine:
npx @usehasp/verify export.json
The package is on npm and the source is on GitHub. Because verification is independent, you do not have to trust the same system that produced the data — the proof travels with the export.
HASP also exposes server-side verification surfaces: a public-key endpoint, a verify-export endpoint, and a live chain-health check on the compliance settings page.
Applies to every org — including Free Evaluation
The full chain applies to every organization, paid and Free Evaluation alike. A prospective customer who registers an agent, watches it execute through the policy gate, and downloads a cryptographically signed export during their evaluation has seen the substrate doing its job — not a feature tour.
| Dimension | Paid org | Free Evaluation org |
|---|
| Integrity-chained audit | Full | Full |
| Database immutability triggers | All sealed rows | All sealed rows |
| Ed25519-signed exports | Available | Available |
| Public verification endpoints | Available | Available |
| RFC 3161 daily anchoring | Anchored | Anchored |
| Retention | Tier-packaged (minimum 7 years for paid) | 30 days; carries forward on conversion |
When a Free Evaluation org converts to paid, the chain continues uninterrupted — no reset, no new genesis hash.
IP-address logging is a compliance floor, not a tier feature — it is included on every paid tier because HIPAA §164.312(b) requires access logs to capture enough context to reconstruct who accessed what from where. Device-metadata logging (user-agent, OS, device fingerprint) is distinct and remains an Enterprise-optional surface.
What PHI events look like in the chain
PHI events (gateway.phi_detected, gateway.phi_redacted, and every subsequent step) are recorded — but the original PHI is never persisted. Rows carry the redacted form plus entity-class metadata only. See BAA Structure for how PHI handling feeds the chain.