Why a ledger
The platform's own records exist to answer one kind of question under pressure: an alert fired at a given moment, was it actually delivered, and what happened next. Before this record existed, that answer lived across separate, ad-hoc logs that could each fail or be missing independently. The evidence ledger is the one place those facts are written the same way, in order, so an incident report built from it does not have several stories to reconcile.
What is recorded
Every alert delivery attempt (email, webhook, Telegram, Discord — delivered, failed, or skipped, with the destination redacted); every critical action you take that reduces a protection Sentinelleai provides — disarming Auto-pause, deleting or disabling a monitor, accepting a risk, suppressing a finding, removing an alert channel — together with the reason you gave and your explicit acknowledgement; and the routine operational events the platform already logs (configuration changes, scheduled runs, anchoring itself). A critical action is written with your actor identity, the request's IP address, a hash of the user agent, and a hash of the session — enough to attribute the action later without the ledger itself holding a raw session token.
What makes it tamper-evident
Each row commits to a hash of the row before it, so altering, deleting, or reordering an earlier row breaks every hash that follows it — verification walks the chain and reports the exact row where it stops holding together, and why (a missing hash, a predecessor that does not match, or a row whose own contents no longer hash to what it claims). The database itself refuses an edit or a delete of an already-hashed row.
Anchoring
Separately from the row-to-row chain, entries are folded into the ledger every five minutes from the other systems that produce them (alert deliveries, incident state changes, and so on), so a report built from the ledger does not miss what those systems recorded. Once a day, the current head of the chain is submitted to the public OpenTimestamps calendars — an independent, Bitcoin-anchored proof that a given hash existed at or before a given time, verifiable by anyone, without needing to trust Sentinelleai or the calendar service again once the underlying Bitcoin transaction has confirmed. A second anchor, on a separate blockchain, is planned but not active on this deployment; where that is the case, the anchor record for that day states that it was skipped and why, rather than reporting a confirmation that did not happen.
Your timeline
Timeline shows your own account's record from the ledger — the alerts sent to you, the actions you took, and when. It is scoped to your own subjects: you see your own history, not another tenant's.
Verifying an export
An exported report can be signed with the deployment's Ed25519 signing key, so whoever holds the matching public key can confirm a given export came from this deployment and was not altered after it was produced. An export is either signed, with the signature and public key attached, or explicitly marked unsigned with the reason why — never silently one or the other.
{
"report": { /* the ledger rows and chain-verification result for this window */ },
"signature": {
"signature": "<base64, 64-byte Ed25519 signature over the report bytes>",
"publicKey": "<PEM-encoded public key that verifies it>",
"alg": "Ed25519"
}
}Reports sent to you
When a protection acts on your assets — Auto-pause sends pause(), Site lockdown engages, Host containment kills or isolates a process — or an incident on your assets reaches a terminal state, Sentinelleai emails you a short notice at the next five-minute mirror tick after the action, drawn straight from the ledger row that was just written. The full, signed incident report follows after a hold window (60 minutes by default), during which an operator can add an analyst note — it appears in the report you receive — or skip the delivery instead, with a reason that is itself recorded.
The consent you signed for that protection is attached to the report exactly as you signed it; a report for a consent recorded before 2026-09-16 has no stored text to attach and says so plainly rather than fabricating what you signed. Every delivery attempt — the notice, the report, a retry, a skip — is itself a receipt in this same evidence ledger, signed the same way any other export is (see above). The report is stored exactly as it was sent and is downloadable from your timeline; the operator reads the identical report from Incident reports — you are never shown a lesser or summarised version of what the operator holds.
What it stops short of
- An anchor proves a hash existed by a given date. It does not prove the content behind that hash was true, only that it has not changed since.
- The chain itself is kept by Sentinelleai; anchoring narrows, but does not eliminate, the trust placed in the operator between anchors.
- Mirrors from other systems into the ledger run every five minutes, so the most recent minutes of activity may not yet appear in an export or a chain-verification check.
- The second, non-Bitcoin anchor is not active on this deployment; any day it would have run instead carries a stated reason for the skip.