HASH CHAIN AUDIT
An audit log that cannot be edited after it is written.
Every agent action becomes a SHA-256 link in an append-only ledger. Each link references the hash of the link before it. Modify anything and the chain breaks at the exact event.
DEFINITION
Hash Chain Audit is the append-only, cryptographically linked record of recorded actions your agents take. Each event is SHA-256 hashed and anchored to the event before it, producing a record that cannot be silently altered after the fact.
THE PROBLEMS IT SOLVES
What goes wrong without it.
01
Your current audit log is just a database table.
Application logs and audit tables live in the same database your engineers, vendors, and incident responders can write to. A row can be updated. A row can be deleted. By the time anyone asks the question, the answer can be whatever you want it to be.
02
Logs do not establish what happened. They establish what is currently said.
An audit log produced by the system being audited is not evidence. It is a self-report. Auditors, regulators, and courts give different weight to a record that can be modified after the fact than to a record that cannot.
03
When agents act autonomously, mistakes scale faster than memory.
An autonomous agent can issue thousands of tool calls in an hour. If something went wrong, the answer is buried in a sea of plaintext logs that nobody verified at the time and nobody can verify later.
HOW IT WORKS · TECHNICAL
The chain, end to end.
01 INGEST
Event arrives at /api/ingest.
The agent SDK posts an event with org_id, agent_id, occurred_at, action, and payload. The endpoint validates the agent passport signature and acquires a per-agent advisory lock so two events from the same agent cannot fork the chain.
02 CANONICALIZE
Payload is reduced to a canonical form.
Object keys are sorted recursively. Whitespace is normalized. Nesting is bounded at depth 10. The canonical JSON is byte-stable. Two clients producing logically identical events produce byte-identical canonical payloads, which produce identical hashes.
03 HASH
SHA-256 over the linked tuple.
The event hash is computed as SHA-256 of the previous event hash, the occurred_at timestamp, the org_id, the agent_id, and the canonical payload, joined with a single delimiter. The genesis block uses 64 zeros as the prior hash.
04 PERSIST
Append-only insert via RPC.
The Postgres function ingest_event_with_hash performs the canonicalization, hash computation, and chain link in a single transaction. The events table is INSERT-only. UPDATE and DELETE are revoked at the role level. The RPC returns event_id, prev_hash, hash, and chain_index.
05 ANCHOR
External transparency log and trusted timestamp.
Periodic chain heads are submitted to Sigstore Rekor and timestamped via RFC 3161 (FreeTSA). Both produce signed receipts verifiable without RANKIGI infrastructure.
06 VERIFY
Recompute every link on demand.
The verify endpoint walks the chain for an org or agent and recomputes each hash from its inputs. If any computed hash does not match the stored hash, verification fails at the exact chain_index. The same logic runs nightly and surfaces a green or red status to the dashboard.
HOW IT WORKS · PLAIN ENGLISH
Why it cannot be tampered with after the fact.
Every event is a sealed envelope. The seal is a hash, which is a fingerprint of the contents. The next envelope's seal is computed from the previous seal, so the envelopes are physically connected. If anyone slips a different sheet of paper into envelope 47, every seal from envelope 47 onward stops matching. The break shows up at the exact envelope. There is no version of the chain in which a single event can be silently altered.
ANALOGY
It works the same way a notarized ledger does, except there is no notary to bribe. The notarization is a mathematical property of the document itself, and a copy of the head of the document is registered with an independent public transparency log so the document cannot be quietly rewritten.
ANATOMY
What lives inside one chain entry.
The event row
What gets written to the events table on every ingestion.
The hash inputs
Exact bytes that go into the SHA-256 function.
The anchor receipt
Periodic external proof that the head existed at a moment in time.
REGULATION MAPPING
What auditors and regulators ask for, and where the chain answers.
| Framework | Reference | Requirement | RANKIGI Answer |
|---|---|---|---|
| SOC 2 | CC7.2 / CC7.3 | System monitoring and detection of unauthorized changes. | Append-only chain with cryptographic verification. Modifications are detectable at the exact chain index. |
| SOC 2 | CC8.1 | Changes to data are authorized and logged. | Database role permissions revoke UPDATE and DELETE on events. All inserts pass through a single signed RPC. |
| EU AI Act | Art. 12 | Automatic recording of events over the lifetime of a high-risk AI system. | Every agent action is recorded with immutable timestamp, identity, and content hash. |
| HIPAA | § 164.312(b) | Audit controls that record and examine activity in systems containing ePHI. | Per-event hash and chain index. Verification endpoint returns the exact event where any modification occurred. |
| FRE | Rule 901 / 902 | Authentication of records as what the proponent claims. | Sigstore Rekor entries provide third-party attestation that the chain head existed at a given moment, verifiable directly against the public transparency log. |
| ISO 27001 | A.12.4 | Logging and monitoring controls. | Hash-chained event log, append-only at the database level, with daily seal snapshots. |
WHO IT IS FOR
Who relies on the chain, and what they read out of it.
CTO and Engineering
You need an audit trail you can show a customer or a regulator without your name being the only thing standing behind it. The chain gives you that property as a function of the data, not as a function of your team's discipline.
- +No instrumentation of agent code
- +p95 ingest under 200ms
- +Postgres-native, no extra storage layer
Compliance and Audit
You need to support evidence for SOC 2 CC7.x, EU AI Act Article 12, and HIPAA § 164.312(b) without writing a custom adapter for each. The same chain answers each framework, with the row-level evidence already mapped.
- +Per-control evidence export
- +Verify endpoint produces signed report
- +Sigstore Rekor receipts attached
CFO and Risk
You need to understand what an unverified audit trail costs in an incident, a settlement, or a contested claim. A tamper-evident chain reduces the cost of being asked the question, because the answer is already produced.
- +Cuts forensic time per incident
- +Reduces audit prep cost
- +Insurable as evidence-grade
QUESTIONS & ANSWERS
The questions a careful reader asks.
What stops an attacker who controls the database from rewriting the chain?
Rewriting the chain requires recomputing every subsequent hash, which is feasible inside a single Postgres instance. It is not feasible against the external anchor. The Sigstore Rekor entry records the chain head at a moment in time, signed and stored in a public append-only transparency log. To forge a rewritten chain, the attacker must also forge a Rekor entry, which requires compromising the Sigstore log itself.
Why SHA-256 and not something newer?
SHA-256 is the most widely audited cryptographic hash currently in use. It is FIPS 140-3 approved, broadly accepted by SOC 2, HIPAA, and EU AI Act auditors, and supported in every Postgres deployment. There is no useful security property a newer hash provides for this use case that SHA-256 does not.
What is the cost of verification?
Verification is linear in the number of events. A million-event chain verifies in seconds because each step is a single SHA-256. RANKIGI runs verification continuously on rolling windows so the dashboard shows a current state at all times, and full historical verification is on-demand.
What if my agent emits events out of order?
The per-agent advisory lock serializes ingestion. Events from a single agent cannot interleave. Across agents, ordering is per-agent, not global. Each agent has its own chain index. The org-level view is a merge of per-agent chains by occurred_at.
Does this work for agents I did not write?
Yes. The sidecar pattern means the agent itself does not need to know it is being observed. Any framework that emits structured action data can be wrapped, and we provide a LangChain callback adapter, with OpenAI Assistants, AutoGen, and CrewAI adapters on the roadmap. For custom agents, the SDK is one HTTP call per event.
Twenty minutes. We open a live chain in your tenant, intentionally tamper a record, and watch verification fail at the exact event.
One SDK call. Your agent's next action becomes the first sealed entry in its chain.