Skip to main content
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:
LayerMechanismWhat it defends against
Hash chainEach 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 immutabilityBEFORE 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 anchoringA 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:
FilePurpose
audit-log.csvThe full audit trail, including integrity-hash columns.
manifest.jsonMetadata, the CSV’s SHA-256 hash, the chain-verification result, and the Ed25519 public key.
manifest.sigA 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.
DimensionPaid orgFree Evaluation org
Integrity-chained auditFullFull
Database immutability triggersAll sealed rowsAll sealed rows
Ed25519-signed exportsAvailableAvailable
Public verification endpointsAvailableAvailable
RFC 3161 daily anchoringAnchoredAnchored
RetentionTier-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.