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.
Who holds the pen? Not the party being audited.
An audit trail in your own database proves nothing to anyone outside your company: your admins could rewrite it and nothing would show. Hash-chaining it in your own app is better: tampering becomes detectable. But you still hold the keys and the checkpoints. Sigilbase moves the record to a third party, and then constrains what that third party can do.
Custody of the record does not mean custody of its contents. Event payloads are redacted from every operator-facing surface (the claim above, with its test), so the party holding your evidence cannot browse it.
Every operator action, including viewing a tenant, lands in a tamper-evident stream of the same construction we sell. Custody is itself on the record, and you can request and verify the entries for your own tenant.
Verification runs offline with an open-source tool, exported bundles stand on their own, and on the Business tier checkpoint roots are anchored outside our reach. Nobody has to take anyone's word, including ours.
The full three-way comparison is on the homepage: who holds the pen?
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.
Reporting a vulnerability.
How to report
Write to [email protected] with what you did, what happened, and enough detail for us to reproduce it. The mailbox is monitored; you will get an acknowledgement within one working day, and the first substantive reply gives an honest assessment of severity and a timeline. If you are not sure whether what you found counts, report it anyway. 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.
What we offer
Credit in the acknowledgments below, with your name and a link if you want them, and neither if you do not; removal on request at any time, no reason needed. We will tell you what was fixed and when. There is no paid bounty: Sigilbase is a very small company, and we would rather say so plainly than imply a reward that does not exist.
Rules of engagement
- Test against your own tenant; anyone can create one free.
- Do not attempt to access another tenant's data. If you find that you can, stop and tell us immediately.
- No denial of service, no load testing, and no social engineering of us or our suppliers. The company is one person; be kind.
- Do not exfiltrate data, and destroy anything you obtain incidentally.
- Give us reasonable time to fix before you publish.
Safe harbour
We will not pursue legal action against anyone conducting good-faith research within these rules, and if a third party asks, we will say so in writing. 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, or the verifier repository's security policy.
The researchers who reported.
These people reported security issues in good faith, and we are grateful. Every name and link appears with the researcher's written consent, and comes down on request at any time.
- 24 July 2026 Abin Joseph
Who else touches your data.
The complete list of third parties that process customer data, what they see, and why. When this list changes, it changes here before the new party processes anything.
| Subprocessor | Purpose | Data processed | Location |
|---|---|---|---|
| Stripe | Payment processing | Billing name, email, payment details | EU/US |
| Amazon Web Services | Application, database, and file hosting; encrypted backups | All service data; payload contents are excluded from every operator-facing surface | UK (London), backups in Ireland (EU) |
| Amazon SES | Transactional email out; inbound support replies | Email address, message content | Ireland (EU) |
| Cloudflare | DNS, TLS termination, and network protection in front of the application | Service traffic in transit | Global edge; US company |
| Mistral AI | AI-suggested support reply drafts, reviewed by a human before anything is sent | Public support-ticket text only, never event payloads or attachments; per-account opt-out honoured | France (EU) |
| Laravel Nightwatch | Application performance and error monitoring | Request metadata and error diagnostics; never event payload contents | US |
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 [email protected]; the full policy is above.
Start recording provable history
Chained, sealed, independently verifiable audit logs, from the first event. Free while Sigilbase is in beta.
Questions first? Write to hello@sigilbase.io.