Security
What we sign, what we store, and what we can see.
This page describes the controls that exist today, in plain terms. Last reviewed 1 October 2026. If something here does not answer a question in your security review, write to us and we will reply.
Per-organization keys
CryptographyVerification docs
| Hash | SHA-256. Events and audit events are hashed as canonical JSON: keys sorted recursively, arrays keep their order. Documents are hashed as the raw file bytes. AI attestations are hashed over the request, with the input and output hashed separately. |
|---|---|
| Signature | Ed25519. One key pair per organization, generated the first time the organization signs a record. |
| Public keys | Published at GET /keys/{domain} once your domain is verified and your organization has signed a record, and returned on proof responses. Fetch the key once and store it with your records. The audit verify helpers in the SDKs accept it as a pinned key. |
| Issuer identity | Organizations verify their domain with a DNS TXT record. Proof pages show whether the issuer's domain is verified. Verified means the issuer proved control of that domain; it does not mean Invoance checked the business's legal identity. |
The write pathHow it works
- POST /v1/eventsAPI key + Idempotency-Key
- Canonical JSONKeys sorted, stable bytes
- SHA-256payload_hash, request_hash
- Ed25519Your organization's key
- Append-only ledgerRows cannot be deleted
Platform
| Transport | TLS for all API and dashboard traffic. Data stores are not reachable from the internet. |
|---|---|
| Edge | API traffic passes through Cloudflare's edge network, with DDoS mitigation, before it reaches the API. |
| Tenant isolation | Every query is scoped to the authenticated organization, and each API key belongs to one organization. |
| API keys | Shown once and stored as a SHA-256 hash. Keys have scopes, can be read-only, and can be limited to IP addresses or CIDR ranges. Several keys can be active at once, so rotate by creating a new key, moving your traffic, then revoking the old one. Revocation takes effect on the next request. |
| Ledger tables | Append-only. Rows cannot be deleted, and signed fields cannot be changed after insert. The time in each record is the API server's clock at ingestion and is covered by the signature. Keep your own copies of proof responses and the public key if you need evidence that does not depend on us. |
| Object storage | Stored files, attestation content, archived audit events, exports and backups are encrypted at rest in object storage. Hash-only anchoring sends no file content. |
| Activity log | Sign-ins, password changes, organization changes, domain verification and other account actions are written to an activity log that your organization can view in the dashboard. |
Access
| Sign-in | Email and password, with protection against repeated failed sign-in attempts, or a passkey (Touch ID, Face ID, Windows Hello or a security key) bound to invoance.com, or Sign in with Microsoft. Two-factor authentication with an authenticator app and backup codes is available to every user in Settings; a passkey sign-in requires user verification on the device and so covers both factors on its own. |
|---|---|
| Roles | Owner, admin and member. Only owners and admins create or revoke API keys. |
| Sessions | A dashboard session lasts 24 hours and can be renewed for up to 30 days. |
| Staff access | Staff access to an organization's data is limited to what is needed to run or support the service. |
Who handles your dataPrivacy notice
| Vercel, Hetzner | Hosting for this website, the dashboard and the API. |
|---|---|
| Cloudflare | Edge network in front of the API, bot protection on forms, and object storage for uploaded originals, AI attestation inputs and outputs, archived audit events, exports and backups. |
| Stripe | Billing. |
| Anyone else | Only where you direct them. Audit streams you configure deliver events to the destination you choose. Invoance does not send your records to anyone on its own. |
AvailabilitySystem status
| Status | Current availability and incident history are published at status.invoance.com. |
|---|---|
| Backups | The database is backed up daily and backups are kept for 14 days. |
| Writes | A 201 response means the record has been durably accepted and is signed and written shortly after. |
Your dataPrivacy notice
| What we store | Events: the payload you send, so it can be served back and re-hashed. Documents: the hash, the reference label and any metadata you attach; the file itself only if you upload it. AI attestations: the full request, including the model input and output text, so the raw bytes can be returned and re-hashed. Audit events: the fields you send. Operators may access stored content when that is needed to run or support the service. If you do not want Invoance to hold content, send a hash in its place; verification works from a hash and never needs the content. |
|---|---|
| What we do not do | Sell data, share it with other customers, or use it to train models. |
| Retention | Ledger retention is set by your plan: 30 days on Developer, 1 year on Builder, 7 years on Growth and Compliance. Enterprise records do not expire unless a period is agreed. When retention ends, events and AI attestations are sealed: get and list no longer return them, but anyone can still verify them. Sealed records stay in the database and are removed only if you ask us to erase your whole organization. Audit log events are archived after your plan's hot window and deleted when their retention period ends. |
| Erasure | Available on request for a stored original file, an AI attestation's stored request text, or a whole organization. For a single record, the ledger row itself, holding the hashes, signature, type label, time and issuer, stays. Send payloads that contain personal data as hashes rather than content. |
| Proof page access | Event, document, audit and AI proof pages open for anyone who has the link. Trace proof pages open only after the owner has made the trace public. Links use random identifiers and are not listed anywhere, but a link posted on another website can be indexed by search engines. Proof page views and hash checks are recorded with the time, result, IP address, country and browser type. Issuers see check results, counts and country, and for document checks a masked IP address with the last part hidden. |
| What a proof page shows | The issuer's name, domain, verification status and logo, the record's ID, the time it was recorded, the hashes, the public key and the signature, plus the type or action label the issuer chose, for audit events the name and ID of the organization the log belongs to, and, for AI attestations, the model provider, name and version and any subject identifiers the issuer attached. Labels are chosen by the issuer and are visible to anyone with the link, so they should not contain personal data. Payloads and metadata are not shown, except on a trace the owner has made public, which shows the full payload of every event in it. |
| Making a record public | Only the organization that owns a record can make it public, from its dashboard, and only for a sealed trace. A public trace shows the full payload of every event in it and the reference label of every document; a second setting also shows the AI prompts and outputs. The owner can switch a trace back to private. Invoance does not notify the people named in a record when a trace is made public; that is the issuer's responsibility. |
| Records about you | If a business recorded something about you through Invoance, that business chose what was sent and how long it is kept, so contact that business first. We act on a record when you or the business give us its proof link or ID. Requests to Invoance go through the contact form. |
Limits
What a proof covers, and what it leaves to you.
Invoance shows that a record has not changed since it was signed. It does not replace your own access controls, and it does not judge whether the recorded statement is true. Invoance operates the ledger and holds each organization's signing key in encrypted form, so you are trusting us to run that service correctly. Offline verification and portable proof bundles exist so that trust is something you can check.
| Verifying without us | Every record's proof, signature and public key can be fetched by API and checked with any Ed25519 library, with no call to us. Audit log events export as CSV or NDJSON with their signatures. A sealed trace can be downloaded as a PDF. When a subscription ends, records keep the retention they were written with. |
|---|---|
| Short or predictable records | A proof page shows the record's hash, not its content. Anyone who already holds an exact copy of the record can confirm it, and anyone who can guess the exact content could confirm that guess the same way. Do not anchor short or predictable payloads on their own; add a random value to the record before hashing, or anchor a hash you computed over the record and that value. |
Send us your security questionnaire.
We answer them directly. Found a vulnerability? Report it through the contact form and mark it as a security report at the top of the message. Every report is read and answered.