Security at Crepuscule
Crepuscule holds confidential financial documents — invoices, IBANs, bank movements — for multiple companies. This page describes, in plain language, how that data is protected. We would rather be precise than impressive: it covers what each control defends against, and what it does not.
SOC 2 Type II: in preparation — no certification claimed yet
Tenant isolation first
Every piece of data belongs to exactly one organization, and every database query is scoped to the authenticated organization — including inside transactions and joins. Identity and organization membership are managed by Clerk; no request without an active organization reaches application data. We treat authorization scoping, not cryptography, as the first line of defense against the most likely real-world failure: one tenant seeing another's data.
Per-tenant envelope encryption
Each organization has its own data-encryption key (DEK). Stored document files and the invoice fields we treat as sensitive — supplier IBAN, QR payment reference, vendor address, raw extraction output — are encrypted with AES-256-GCMunder that key. The per-org keys are themselves encrypted ("wrapped") by a master key that is never stored alongside the data. Each ciphertext is additionally bound to the tenant and the specific column it belongs to, so a value moved to another row, column, or organization fails authentication rather than decrypting.
Deliberately not encrypted, because the matching engine has to query them: supplier names, invoice numbers, amounts, dates, currencies, and imported bank movement data including counterparty names, counterparty IBANs and payment references. These rest on tenant scoping and provider-side at-rest encryption instead.
What this buys: a leaked database dump, storage bucket, or backup yields ciphertext, not documents — and one tenant's key can be destroyed without touching any other tenant. What it does not buy: a compromised running application still holds decryption capability by necessity, which is why the scoping above matters most.
Private document storage
Uploaded PDFs are encrypted with the organization's key and kept in a private blob store with no publicly addressable URLs. The browser first writes the file to a private staging area, from which the server reads, encrypts and moves it — so an upload is briefly held unencrypted in that staging area, and anything left there is swept within the hour. Documents are only ever decrypted server-side, inside an authenticated, organization-scoped request.
Key custody and crypto-shredding
The master key lives in the deployment environment (with an offline escrow copy and a documented rotation runbook), separate from the database that holds the wrapped per-org keys — so neither store is useful on its own. When an organization offboards, a 7-day grace period runs and then its key is destroyed. Everything encrypted under that key becomes unreadable at that moment, in live storage and in any later backup alike.
Two honest limits on that, spelled out in the privacy policy: a backup taken beforethe key was destroyed still holds the key in wrapped form until it ages out of our providers' retention windows, and the fields listed above as deliberately unencrypted are untouched by key destruction — those are removed only by deleting the underlying records, which we will do on request.
Audit logging
Every financial and security-relevant action — uploads, extractions, match decisions, postings to bexio, key lifecycle events, API-key use — is recorded in an append-only audit log with the acting user, organization, and timestamp. Money is handled as integer cents end-to-end to keep records exact.
AI processing
Invoice extraction uses Anthropic's Claude API. Anthropic does not train models on API inputs. Documents are sent for extraction only — never for advertising, profiling, or model training. Extraction requests are subject to Anthropic's standard API retention terms; we are enabling a zero-data-retention configuration before general availability.
Subprocessors
| Provider | Role | Location |
|---|---|---|
| Clerk Inc. | Identity, authentication, and organization management | United States |
| Vercel Inc. | Application hosting, request logging, and encrypted document storage (Vercel Blob) | United States; document storage and compute in the EU (Frankfurt) |
| Neon Inc. | Managed Postgres database | EU (Frankfurt, on AWS infrastructure) |
| Anthropic PBC | AI extraction of invoice data from uploaded documents | United States |
| Upstash Inc. | Distributed rate limiting | EU (Frankfurt) |
| Functional Software, Inc. (Sentry) | Error and exception tracking | United States |
| bexio AG | Accounting integration — your own ledger | Switzerland |
Details and data-protection terms are in the privacy policy.
Responsible disclosure
If you believe you have found a vulnerability, please email yann.borie@superstellar.io with enough detail to reproduce it. We will acknowledge reports promptly, keep you informed, and not pursue good-faith research conducted without data exfiltration or service disruption.
What we do not claim
We hold no security certifications today. SOC 2 Type II is in preparation: the controls on this page are designed to that standard, and this page will be updated when an independent audit is complete. Questions about our posture are welcome at the address above.