SigilbaseEvidence that holds up.
Your audit logs are rows in a database you control. To an auditor, a regulator, or the other side of a dispute, that is an assertion, not evidence.
What an auditor sees
The open verifier's report on an exported bundle. An example, not a live result.
$ php verify.php evidence-bundle.zip PASS: 500 events and 5 checkpoints verified for stream 01a090b0-2c03-7086-b41b-0a058af07426 (1..500). No event has been modified, deleted, or reordered, and every checkpoint signature is genuine.
The verifier recomputes the hash chain and checks every signature with no connection to Sigilbase. A modified, deleted or reordered record fails the check, and the failure names the sequence number.
A pass shows the record is intact, not that what it recorded was true. What a pass does and does not prove, or check a bundle in this browser.
Who holds the pen?
Where a record lives decides what it proves. Most audit trails live in the audited party's own database, which is why auditors are handed screenshots and CSV exports and asked to trust them.
-
In your database
Your admins can rewrite it and nothing shows the change.
An assertion.
-
In your app, hash-chained
Better: tampering is detectable. But the party being audited still holds the keys.
Detectable, but still yours.
-
In Sigilbase
A third party holds the record and anyone can verify it, with no one's word taken, including ours.
Evidence.
How an audit log becomes evidence
-
Send events
Your application posts each event, with its actor, action and payload, to the API.
-
Chain them
Each event is hashed with SHA-256, and each hash includes the one before it.
-
Seal and sign
Every few minutes a Merkle checkpoint seals the batch, signed with an Ed25519 key.
-
Export and verify
Any range exports as a bundle that the open verifier checks offline.
One event, as your application sends it.
POST /api/v1/streams/billing-events/events
Authorization: Bearer sgb_example.xxxx
{
"occurred_at": "2026-09-11T14:22:31.000000Z",
"actor": "svc:billing",
"action": "invoice.voided",
"payload": {
"invoice_id": "inv_9f21",
"reason": "duplicate"
}
}
The concepts behind the four steps, explained in full.
Built for the moments a record gets questioned
-
AI audit records
What an automated system or agent saw, decided and did, in a record no one can quietly alter afterwards.
-
SOC 2 audit evidence
Control events sealed as they happen; your auditor verifies the export offline.
-
Disputes between businesses
When each side controls its own logs, neither is evidence. Sigilbase holds the record in between.
-
SEC 17a-4 recordkeeping
The audit-trail alternative, with a trail an examiner can verify independently.
-
Enterprise audit logs
The customer-facing audit logs enterprise procurement asks for, in an afternoon.
-
Anything you run
Every source we collect from, with a page each saying what can be ingested and where its connector stands.
Two questions, answered plainly
-
How long does Sigilbase retain audit events?
Forever, on every plan, including the free one. Retention is never a paid feature, ingestion never stops because of billing, and if you stop paying your history is never deleted.
-
Does using Sigilbase make my company SOC 2 or PCI DSS compliant?
No single tool makes you compliant. Sigilbase strengthens the audit trail and log integrity controls those frameworks require, and gives your auditor evidence they can check by computation rather than on trust. Certification still depends on your controls and your auditor's assessment.
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.