Claims you can test, not assurances you must trust.
A product whose whole point is that you should not have to trust your log vendor cannot ask you to take its security on faith. So this page states the security model as claims, each written so that you, or your auditor, can check it. The docs security page is the deep version, with the exact tests.
Six claims, each with its test.
Platform operators cannot read your event payloads.
Customer event payloads are redacted from every operator-facing surface: support tooling, admin screens, and operational queries show event metadata, never payload contents. The payload exists to be hashed, sealed and returned to you.
Test: ask us a support question about a specific event; we have to ask you for the payload, because we cannot look it up.
Every operator action is itself on the record.
Sigilbase runs on Sigilbase: platform operations, including an operator so much as viewing a tenant, are recorded in a tamper-evident stream of the same construction we sell, chained, sealed and signed like any customer stream.
Test: request the platform ledger entries for your own tenant and verify the export like any other bundle.
Accepted events cannot be updated or deleted.
Three independent layers: the application has no update or delete path, the database rejects updates and deletes at the trigger level, and the mathematics makes any bypass of both detectable by anyone holding an earlier export.
Test: attempt an update on a sealed event on your own instance's data and read the database error.
Compromising our database does not yield the ability to sign.
Checkpoints are signed with Ed25519 and the private keys live outside the application database. Key rotation is append-only: keys retire with their timestamps, they are never deleted, so old bundles stay verifiable forever.
Test: fetch every public key, retired ones included, from /api/v1/keys with no credentials.
API keys cannot be recovered, only revoked.
Key secrets are stored only as argon2id hashes; the full token is shown once at creation and exists nowhere at rest, for you or for us. Authentication failures return one identical message, so key ids cannot be enumerated.
Test: revoke a key and replay a previously working request; it fails on the next call.
This site runs nothing that watches you.
No analytics, no trackers, no third-party fonts or CDNs, on any page of this site. The one exception is Cloudflare Turnstile, loaded solely to guard the waitlist form against automated abuse; it is not analytics and does not profile you.
Test: open the network inspector on any page: this site and, where the form is present, the Turnstile challenge. Nothing else.
What a revoked key looks like.
$ curl -H "Authorization: Bearer sgb_k7f2…4kJq" \
https://api.sigilbase.io/v1/streams/prod-audit
200 OK
# key revoked in the dashboard
$ curl -H "Authorization: Bearer sgb_k7f2…4kJq" \
https://api.sigilbase.io/v1/streams/prod-audit
401 {"message": "Invalid or revoked API key."}
A revoked key fails on the very next request. The same message covers unknown, revoked and wrong keys, so the API never confirms which key ids exist.
Every stream, event, checkpoint and key belongs to exactly one tenant, scoped on every access path. A request for another tenant's stream returns 404, not 403: the API does not confirm the stream exists.
Every night, every stream is re-verified end to end: chain, Merkle roots, checkpoint chain, signatures. A failure is the loudest state in the product and cannot be dismissed without resolution.
Who else touches your data.
The complete list of third parties that process customer data, what they see, and why. Rows marked TBD are decisions not yet made; they will be filled in, not quietly appended.
| Subprocessor | Purpose | Data processed | Location |
|---|---|---|---|
| Stripe | Payment processing | Billing name, email, payment details | EU/US |
| TBD Hosting | Application and database hosting | All service data, payloads redacted from operator view | To be confirmed, UK/EU intended |
| TBD Transactional mail | Account and billing email | Email address, message content | To be confirmed |
Event payload contents are not shared with any subprocessor beyond the hosting infrastructure the service runs on.
The testable version lives in the docs.
Every claim above is expanded in the documentation with the exact request, response and failure mode: the security model, how verification works, and the evidence bundle format a third party can reimplement from scratch.
To report a vulnerability, write to security@sigilbase.io; the full policy is below.
Reporting a vulnerability.
Write to security@sigilbase.io with what you found and how to reproduce it. The canonical, machine-readable statement of this policy is /.well-known/security.txt.
In scope are the Sigilbase application and API, and the open-source verifier. Out of scope are the static pages of this marketing site, volumetric denial of service, and social engineering of the company, which is one person. Be kind.
You will get an acknowledgement within 3 business days. The first substantive reply gives an honest assessment of severity and a timeline. If you would like credit, your name or handle goes in the acknowledgments below.
Good-faith research that respects user data and service availability will not be met with legal action. We will work with you, not against you.
Soundness bugs in the verifier, anything that makes a tampered bundle verify, are the most severe class of issue we have. Read how the verifier works.
Acknowledgments.
No reports yet. Be the first name here.
Join the waitlist
Building now. Early access for teams that need evidence-grade logs.
Could not save your email. Try again or write to hello@sigilbase.io.
No spam, one email when it opens.