ProductAudit & Trust

We don't ask you to
trust our logs.
We let your auditor verify them.

Every action across every HASP surface — chat, documents, API calls, PHI scans, admin events — is signed with an Ed25519 key bound to your tenant, then chained. Any tampering breaks the chain at that point and everything after it. Your auditor downloads the export, runs the verification recipe on their own machine, and confirms integrity without any HASP software in the loop.

Ed25519 signature

Every entry signed with a key bound to your tenant. Public key is published. Signature verifiable with standard cryptography tooling — no proprietary SDK.

Hash-chained

Each entry references the hash of the previous one. You can't quietly edit a past entry — it breaks every entry that comes after it.

RFC 3161 timestamp anchor

Chain checkpoints are countersigned by an external Time Stamping Authority. Timestamps don't depend on HASP's clock — they're attested by a third party.

Compliance · frameworks we ship under
Active HIPAA BAA included
AOC under NDA SOC 2 Type II · inherited
AOC under NDA HITRUST r2 · inherited
EU + UK GDPR Art. 17 · 20 · 30
Active + CPPA-ready PIPEDA / CPPA Canada
Q3 2026 ISO 27001 In progress
What everyone else offers

Logs.

A dashboard with timestamps and event types. Written by the vendor, stored by the vendor, exported at the vendor's discretion. When an incident happens, the vendor tells you what the logs say. You have no independent way to confirm they haven't been altered.

  • Stored and controlled by the vendor
  • No way to detect retroactive modification
  • "Trust us" is the audit answer
  • Fails cross-examination in a contested audit
What HASP offers

A signed, chained, independently verifiable record.

Every entry is cryptographically signed at write time. Entries are chained — each one references the hash of the one before it. Any modification to any past entry is detectable immediately, without asking HASP. Your auditor runs the verification on their machine; HASP is not in the loop.

  • Signed at write time, chain is tamper-evident
  • Tampering breaks the chain — detection is automatic
  • Verification recipe runs on the auditor's machine
  • Stands up under cross-examination

Coverage

Every surface. Every action. One chain.

The audit chain is not a separate product bolted on — it's the substrate every HASP surface writes to. There is no action you can take in HASP that doesn't produce a signed audit entry — including every PHI scan, where the categories detected and the action taken (allow, redact, or block) are recorded. For how detection differs from removal, see PHI scanning vs. redaction.

Assistant
  • Every chat message sent and received
  • Every document upload and ingestion
  • PHI scan: categories detected, action taken, user, prompt
  • Model selection and token usage
Public API
  • Every API call with caller identity (user / key / agent)
  • PHI scan result per request
  • Credit usage and budget enforcement events
  • Rate limit enforcement and model allowlist enforcement
Studio
  • Every Studio build conversation message
  • Every app version created, previewed, and published
  • Every app access event (authenticated user + timestamp)
  • Rollback events with version restored
Agent SDK
  • Agent delegation issuance, refresh, and revocation
  • Pre-action tool authorization allow / deny with rationale codes
  • Agent Actions metering entries per approved invocation
  • A2A handshakes binding external orchestrators to audit sequence IDs
Admin & compliance
  • BAA countersignature and status changes
  • Org member adds, removals, and role changes
  • Audit export downloads (who exported, what range)
  • Policy changes and model allowlist modifications

Verification

How your auditor verifies the chain

Six steps. Standard tooling. No HASP software required. Read the full verification recipe.

Export the audit log

Download via the admin UI or the API. Output is plain JSON — one entry per line, with timestamp, actor, action, prev_hash, hash, and signature fields.

Verify the hash chain

For each entry, compute SHA-256 of the canonical entry fields. Confirm it matches the stored hash. Confirm the stored hash matches the prev_hash of the next entry. Any mismatch identifies the break point.

Verify each Ed25519 signature

Retrieve the tenant public key from /trust/keys/{org_id}. For each entry, verify the signature against the entry hash using the public key. Standard Ed25519 — works with OpenSSL, libsodium, Node crypto, Python nacl.

Verify the RFC 3161 timestamp anchors

Periodic chain checkpoints include a TSA token. Verify the token using the TSA's public certificate (published). Confirms the chain existed before the timestamp — independent of HASP.

Cross-reference PHI scan events

Filter the export for phi.scan.* events. Confirm every chat message has a corresponding scan entry. Confirm detected categories and the action taken (redact / allow / block) match your org's configured policy.

Deliver the verification report

The recipe produces a machine-readable verification report: chain_valid, signature_valid, tsa_valid, phi_coverage, entry_count. Attach to your audit package. Done.

Capabilities

Everything in the audit chain

Every action signed

Chat turn, document upload, RAG retrieval, API call, BAA event, PHI detection, admin action — every audit-relevant event is signed with an Ed25519 key bound to your tenant. The public key is published.

Hash-chained entries

Each entry references the cryptographic hash of the previous entry. Tampering with a past entry breaks the chain at that point and every entry after it. Detection is immediate.

RFC 3161 timestamp anchoring

Periodic chain checkpoints are countersigned by an external Time Stamping Authority. Timestamps don't depend on a HASP server clock — they're attested by an independent third party.

Plain-JSON exports with verification recipe

Any time period exportable as plain JSON plus a verification recipe. Auditors clone to their own machine, run the recipe, confirm the chain — without any HASP software in the loop. See the verification recipe.

PHI detection events on the chain

Every PHI scan that fires gets one audit entry: which categories detected, which action taken (redact / allow / block), which user initiated, which prompt was scanned. Procurement asks; the answer is in the chain.

7-year retention with monthly partitions

Seven-year retention on every tier. Monthly partitions for export performance. Chain remains continuous across partitions; verification covers the full retention window. Enterprise can extend beyond seven years on a custom contract.

Audit chain integrity is not a paid upgrade — signed, tamper-evident, and verifiable at every plan tier, including Solo.

Tier-1 wrappers say 'we're HIPAA compliant.' We show signed audit exports.

Reproducible verification on your auditor's machine — stands up under cross-examination.

Sample export and full verification recipe published — try it before you sign anything.

FAQ

Every action in the system — chat turn, API call, document upload, RAG retrieval, internal-app event, BAA lifecycle event, PHI detection, admin action — is recorded as an immutable entry in a hash-chained log. Each entry references the cryptographic hash of the previous entry, so any tampering with a past entry breaks the chain at that point and every entry after it. Entries are signed with an Ed25519 key held by HASP; the public key is published so customers and auditors can verify signatures independently.
Yes. The audit-export format is plain JSON plus an Ed25519 public key and a verification recipe. An auditor can clone the export to their own machine, run the verification script, and confirm both the hash chain and the signature without any HASP software. Most HIPAA AI vendors claim 'audit logs.' HASP gives you a record an auditor can independently verify — without calling us, without special software, without trust.
It's a standard for getting an authoritative third-party timestamp on a piece of data. HASP anchors audit-chain checkpoints to an external Time Stamping Authority so the dates on your records aren't just 'whenever our server clock said it was.' If a regulator or auditor questions when an event happened, the answer is signed by an independent third party.
Seven years on every paid tier — Solo through Business. Enterprise can extend beyond that on a custom contract. Logs are partitioned monthly for export performance; the chain remains continuous across partitions and verification covers the full retention window.
Yes. Download the sample audit export and follow the verification guide — six steps covering hash chain, Ed25519 signatures, and TSA timestamp anchors.
Chain integrity is checked on every export. If a break is detected, the export surfaces the seq number where the break occurred and the partition it lives in. We notify customers promptly upon confirmation per the incident response process documented at the Trust Center.
Yes — multiple ways, on every tier including Free Evaluation. The Ed25519-signed audit export (verifiable on your own machine, no HASP software required) and the public verification API are universal. CSV downloads from the admin UI are included on Business and Enterprise. The audit-export API endpoint is available on the API plan for scheduling daily or hourly exports to your own cold storage. You're never locked in to retrieving logs through our admin UI.

The full platform

The audit chain covers all of these

Every HASP surface writes to the same chain. One BAA, one signed audit trail, one verification process — regardless of which surfaces your team uses.

Audit & Trust

Try the verification
before you sign anything.

Download the sample export. Run the recipe. Confirm the chain holds on your own machine. Then decide if this is the audit story you want to bring to your next security review.