Press enter or click to view image in full size
This guide walks through how to use the tamper evident checksum built into ZizkaDB, based on SHA-256, in the order a CIO, head of risk, or vertical AI team would actually do it. The checksum sits underneath lineage, replay, and point in time retrieval, because all three assume the record is true. These steps are how you prove it.
Before you start: what SHA-256 is
SHA-256 is a cryptographic hash function. You give it any piece of data, a sentence, a log entry, an entire file, and it returns a fixed length fingerprint, 64 characters long, that represents that data.
Three properties make it useful for auditing.
It is deterministic. The same input always produces the same fingerprint. Anyone, at any time, can recompute it and get the same answer.
It is extremely sensitive. Change a single character in the input, one digit in a transaction amount or one word in a decision, and the fingerprint changes completely.
It is one way. You cannot work backwards from the fingerprint to the original data, and in practice you cannot craft a different input that produces the same fingerprint. SHA-256 is part of the SHA-2 family standardized by NIST and is widely used in banking, software signing, and certificate infrastructure.
Think of it as a tamper seal on a package. The seal does not stop anyone from opening the package, but if someone does, you can see it.
Step 1: Decide what needs to be provable
A log is only worth as much as your ability to trust it. An auditor, regulator, or court asks not only what the record says, but whether it could have been changed since.
List the situations where your records may be questioned: customer disputes, supervisory reviews, security questionnaires from enterprise buyers, internal investigations. For agentic AI this matters more than usual, because if an agent made a contested decision, the log of that decision is the evidence. This list becomes your acceptance criteria for the steps below.
Step 2: Enable continuous event logging
Connect your agent to ZizkaDB so every event is captured as it happens: user messages, decisions, LLM calls, tool invocations, and responses. Every event recorded gets a SHA-256 checksum computed from its content, stored alongside the event.
Check completeness before moving on. Run test sessions and confirm each one can be reconstructed from first message to final response. Checksums protect what is recorded, so gaps in capture are gaps in protection.
Step 3: Lock down the surrounding controls
A checksum makes tampering detectable, not impossible. That is what tamper evident means. Prevention comes from the controls around it, so set these up now:
- Tenant isolation, so each team or business line only accesses its own records
- Scoped API keys, so each agent can only write what it should
- Restricted write and administrative access to the database
- Self hosted or VPC deployment where data residency or security requirements demand it
The strength of the guarantee depends on how checksums are stored and protected. If an attacker could rewrite both an event and its checksum, a standalone checksum would not catch it.
Step 4: Add an external layer for stricter requirements
If your requirements are strict, as they often are in banking, add protection the database administrator cannot override. Options include periodically exporting checksums to storage that the administrator cannot modify, or anchoring checksums externally on a schedule. Treat the checksum as one strong layer, not the only layer.
Step 5: Verify integrity on a schedule
Verification is simple: recompute the checksum from the stored event and compare it with the one on record. If they match, the event is exactly as it was when written. If they do not, something changed, and you know which event.
Do not wait for an incident. Run verification routinely, for example weekly, and assign an owner for reviewing any mismatch. Not every integrity problem is malicious. Bad migrations, storage faults, and buggy scripts also alter data, and checksums flag them regardless of cause.
Step 6: Build a procedure for when someone questions a record
Write a standard procedure so any analyst can follow it, not only the engineer who built the system:
- Pull the session or events in question.
- Run checksum verification on them.
- Record the result in the case file.
- Hand the evidence, with the verification result, to the auditor, ombudsman, or counsel.
This turns “trust us” into “here is the verification result.”
Step 7: Prepare your answer for security reviews
Enterprise buyers in banking, insurance, and health ask how you protect the integrity of audit data. Prepare a short answer that names the standard, explains that every event is checksummed, describes the surrounding controls from Steps 3 and 4, and offers a demo of verification. A concrete answer built on an algorithm they already trust shortens the conversation.
Step 8: Map it to regulation, with the right expectations
The EU AI Act expects high risk systems to maintain logs that support traceability and post market monitoring (Article 12), and expects technical robustness and cybersecurity (Article 15). In banking, DORA and supervisory record keeping expectations point the same way. None of these name SHA-256 specifically, and a checksum alone does not make a system compliant. It gives you a concrete, verifiable control supporting the claim that your logs are reliable, which is the claim regulators are testing.
Step 9: Run a pilot and measure
Run verification alongside your existing processes and measure before and after:
- Time to establish that a questioned record can be trusted
- Time spent answering integrity questions in security reviews
- Time spent on manual spot checks for tampering
If nothing moves, this is mostly insurance for you right now, and that is fine.
What the business case looks like
These figures are modeled assumptions, not measured results. Replace them with your own.
Assume 10 situations a year where record integrity is questioned, at 100 euro per hour. Establishing trust manually, through access logs, change history, and written attestations, takes about 3 days each, costing around 24,000 euro a year. With checksum verification it takes about an hour each, costing about 1,000 euro a year.
Assume 10 enterprise deals a year where integrity comes up, and an unclear answer adds about 3 days of back and forth per deal. That is roughly 24,000 euro in effort and, more importantly, delay. A direct answer removes most of it.
Manual spot checks for tampering might take 2 days a quarter, around 6,400 euro a year. Automated verification reduces that to a small review cost.
Together that is in the range of 50,000 euro a year for a mid sized team. The larger value is that a record you can prove is intact is worth far more in a dispute than one you can only claim is intact.
What checksums do not do
They do not stop deletion of whole records unless you also track sequence or counts. They do not prove the logged content was true when written, only that it has not changed since. They do not replace access control, backups, or monitoring. They are one control in a layered design.
Why ZizkaDB uses SHA-256
It is a standard that auditors and security teams already trust, so nobody has to evaluate a custom invention. It is cheap, adding negligible overhead per event. And it is independently verifiable: anyone with the stored event can recompute the checksum with open tooling, which fits ZizkaDB’s open source and self hosted approach, so you do not have to trust the vendor to verify the record.
Where to go from here
The whole premise of auditability is that someone else can rely on your record. Lineage explains why an agent acted, replay shows what happened, and at() shows what the system looked like. SHA-256 checksums are the quiet foundation that lets you say, with evidence, that the record is exactly what was written at the time.
If you tell me your vertical and what integrity or audit requirements your customers ask about, I can tailor these numbers to your case.
Want to test ZizkaDB on your agent? Try our open source version here: https://github.com/ZIZKA-AI-SL/ZizkaDB
Interested in a design partnership? Fill in the form on our site or reach me directly at founder@zizka.ai