How your data is held
Audkit stores other people's audit trails, so the honest thing to publish is the mechanism, not a badge. This page is the reference for security questionnaires — everything on it is a description of what the system does, not an aspiration.
Encryption
Event payloads are encrypted at rest with a per-event key, with the commitment-blinding nonce sealed inside the encrypted blob. The database stores ciphertext and hashes; the plaintext of an event body is not retained in queryable columns. All traffic is TLS in transit.
Because payload commitments are nonce-blinded, a destroyed payload cannot be dictionary-attacked to confirm what it contained — knowing the hash of a shredded event tells an attacker nothing about its content.
Append-only storage
Database triggers reject UPDATE, DELETE and TRUNCATE on the event tables for every role. There is no API that edits or deletes an event. The single sanctioned deletion path is the retention function, which crypto-shreds expired payloads while leaving the verifiable Merkle leaf skeleton intact.
A database superuser can bypass triggers — no storage-level control can prevent that. The actual guarantee is detection: signed, externally anchored tree roots make a rewrite provable by anyone holding an older root, including you.
What is published publicly
Audkit publishes signed tree heads hourly to Sigstore Rekor, a public transparency log outside Audkit's control. That is what makes tamper-evidence meaningful rather than self-attested — but it means some metadata leaves our infrastructure permanently. Each anchored entry contains exactly:
- the protocol version, an opaque
projectId, and the stream name - the tree size (a count of events) and the root hash at that moment
- a timestamp, our signature, and the Audkit service public key
No event content, actor, target, or metadata is ever published. What an observer can infer is that a given opaque project id existed and how many events it held at a point in time. Rekor entries are permanent and cannot be withdrawn, so this is disclosed here rather than buried: erasure of your event data does not and cannot remove previously anchored roots. Self-hosted deployments can disable anchoring entirely.
Retention and deletion
Retention is per project — 30, 90, 180 or 365 days, 7 years, or forever, defaulting to 90 days. Expired events are crypto-shredded daily: the encrypted payload row, its key, and the sensitive projections are destroyed. Legal holds pause shredding for matching events and are themselves recorded in a separate, verifiable control-plane log.
Access and authentication
Dashboard access is email and password with a mandatory emailed six-digit confirmation code; sign-in codes never create accounts. Ingestion uses project-scoped API keys carrying explicit scopes — log:write, log:read, log:export, log:verify— shown once at creation and revocable at any time. Every member of an organisation can access that organisation's projects; this is deliberate, and the boundary you should model is the organisation, not the project.
Customer-held signing keys
You can sign events with your own Ed25519 key before they reach us. The private key never leaves your process and Audkit stores only the public half, so we cannot mint an event in your name. This is available on every plan, including the free one, because it is the control that makes the rest of this page checkable rather than trusted.
Subprocessors
Audkit uses the following subprocessors. Material changes to this list will be published here.
| Provider | Purpose | Region |
|---|---|---|
| Vercel | Application hosting and compute | United States |
| Neon | Postgres — the authoritative event store and Merkle trees | AWS us-east-1 |
| Tinybird | Analytics mirror — aggregate counts and index dimensions only, never payload content | GCP europe-west2 |
| Upstash Redis | Rate limiting and billing state | Managed |
| Upstash QStash | Background jobs and scheduled tasks | eu-central-1 |
| Upstash Realtime | Live dashboard streaming | Managed |
| Resend | Transactional email — sign-in codes, digests, alerts | United States |
| Stripe (via Autumn) | Payments and subscription billing | United States |
| Sigstore Rekor | Public transparency log — receives tree roots only (see below) | Public / global |
Audit data is processed in both the United States and the European Union. If your deployment requires a single jurisdiction, contact us before sending production data.
Certifications
Audkit is not currently SOC 2 certified. We would rather say so plainly than imply otherwise: the verifiability described on this page is a property you can check yourself with the open-source audkitCLI, independently of any audit we have or haven't passed.
Reporting a vulnerability
Email security@audkit.dev. Please include enough detail to reproduce. We will acknowledge receipt and will not pursue legal action for good-faith research that avoids privacy violations, data destruction, and service degradation.