A cryptographic receipt of an AI action is a record that the checking layer creates at the moment it decides on an agent’s action: what the agent wanted to do, which rule it was checked against and what the result was. Receipts are linked into a chain by SHA-256 hashes, and the tip of the chain is regularly fixed with an external witness. So an outsider (an auditor, a court, an insurer) can recompute the chain and replay the decisions on their own computer, trusting neither the agent’s owner nor the developer of the checking layer. An ordinary log cannot do this: its administrator can quietly rewrite it.
In brief
- The receipt is written before the action executes, not after: it records a decision against a rule, allow or block.
- Both allows and blocks are recorded. Otherwise, after an accident there is no way to tell why a destructive call went through.
- Hash chain: each receipt contains the hash of the previous one; changing one character in an old record breaks all later ones.
- External witness: once a day the hash of the chain’s tip is fixed in the public OpenTimestamps calendars. One hash goes out, with no data.
- Checking without trust: an outsider recomputes the chain, matches the anchors and replays the decisions with their own instance of the solver.
How does a receipt differ from a log line?
A log line records that an event happened. A receipt records that an action was checked against a specific rule and what the answer was, and it links this record to its neighbours so it cannot be quietly changed.
| Log line | Cryptographic receipt | |
|---|---|---|
| When it is written | After the action | At the moment of decision, before execution |
| What it records | The fact of an event | The request, the rule (by fingerprint), the check’s answer, the outcome |
| Who can correct it | The server administrator, and the agent itself if it has the rights | No one, quietly: a change breaks the chain and diverges from the anchor |
| Who checks it | Whoever is trusted on their word | Any outsider on their own machine |
| Evidential weight | Depends on trust in the owner | Follows from recomputation |
What does a receipt record?
In the architecture described in the institute’s book “Proven Action” (Chapter 10), a decision receipt has four groups of fields:
- Whose action and what kind: the tenant, the channel and the class of action, for example sending data out, deletion, a push to a repository, stopping a service.
- Observed facts and the rule: the values the classifier saw and the server established, and the rule: its class, revision number and the SHA-256 fingerprint of its text. There is no human signature in the receipt: the rule’s revision is fixed by the fingerprint, and the rule’s text is stored next to the chain once per revision.
- The decision: whether the action is admissible, the solver’s answer, the grounds for admission or the repair conditions, the mode (advice, block), the final verdict and the decision time.
- The link to the chain: the hash of the previous receipt and the hash of this one.
Why are receipts linked into a chain?
So that a record cannot be deleted, inserted or reordered. The hash of each receipt is computed from the hash of the previous one and its own body: Hₙ = SHA-256(Hₙ₋₁ ∥ Pₙ). If even one character changes in receipt k, its hash changes, and with it the hashes of all later ones. Recomputing the chain shows where it breaks.
A chain has a limit: whoever controls the whole disk can rewrite receipt k and recompute all hashes after it. The chain stays internally consistent. That is why an external witness is needed.
The external witness: OpenTimestamps
Once a day the hash of the chain’s tip (one 64-character string) is fixed in the public calendars of the OpenTimestamps protocol. The calendars aggregate fingerprints into a Bitcoin transaction and return a proof of existence. After that, the chain up to the fixed tip cannot be rewritten unnoticed: a new chain will not match the anchor, which is kept outside the owner’s control.
The contents of the receipts cannot be recovered from one tip hash, so no requests, file names, amounts or personal data go out. The confidentiality of the closed perimeter is preserved.
How to check receipts without trusting the owner?
The checker receives the chain of receipts, the rule texts and the verifier, and takes the anchors with their timestamps from the open verification kit. Then three steps on their own machine, with no connection to the checked server:
- Recompute the chain: the hashes of all receipts match, so no records were deleted, inserted or changed.
- Match the anchors: the chain’s tips match the fingerprints fixed in OpenTimestamps on their dates.
- Replay the decisions: for each receipt, give the rule text and the observed facts to their own instance of the solver and get the same answer.
The open part of the verification kit (chain anchors, their OpenTimestamps proofs and the integrity verifier) is published at asi5.ru/console/verify/. According to the book, on 14 October 2026 the verifier replayed 4,958 decisions out of 4,958 recorded in the chain; this replay was run by the institute itself, and an independent checker has not yet done it. The procedure is on the page of the independent verification protocol.
What a receipt proves, and what it does not
| Proves | Does not prove |
|---|---|
| The action was checked against the rule of this revision, and the check gave this answer | That the rule itself was good: a bad rule will honestly let a bad action through |
| Records up to the fixed anchor were not deleted or changed | The integrity of records after the latest anchor: only the chain protects them until the next fixing |
| The decisions can be replayed by an outsider | Compliance with a regulator’s requirements: the organization and the certification body establish that |
A receipt turns an argument from “trust us” into a recomputation. Responsibility for the rules still lies with the person who approved them.
Who needs a receipt and why
- A CTO, to reconstruct what the agent did even if the agent had access to the logs.
- An owner and a director, to show that the agent’s actions were checked against approved rules; the assessment of reasonable management depends on it (director liability).
- A security service and an operator of a state information system, to keep an event log that cannot be selectively corrected (logging AI actions with GOST R 34.11-2012, in Russian).
- An insurer, to assess a loss from the record rather than from the policyholder’s explanation (cyber insurance and AI agents).
Frequently asked questions
What is a cryptographic receipt of an AI action?
A record of a decision on an AI agent’s action: what it wanted to do, which rule it was checked against and with what result. Receipts are linked into a chain by SHA-256 hashes, and the chain’s tip is fixed with an external witness, so the record cannot be quietly changed and an outsider can check it.
How does a receipt differ from an ordinary log?
A log is written after the event and kept by the owner, who can correct it. A receipt is written at the moment of decision, records the rule and the check’s answer, and is linked to neighbouring records so that any change is found by recomputation.
Why record allowed actions, not only blocks?
To understand after an accident why a destructive action went through: a gap in a rule, a soft “advice” mode or a classifier error. If only blocks are kept, there is nothing to answer that question with.
How can a chain of receipts be checked without trusting the owner?
Recompute the hashes of all receipts, match the chain’s tips against the OpenTimestamps anchors and replay the decisions with your own instance of the solver using the rule texts. All of this runs on the checker’s machine, with no connection to the checked server.
Does company data leave the perimeter when fixed with the external witness?
No. Only the hash of the chain’s tip goes out: 64 characters from which the receipts’ contents cannot be recovered; requests, file names, amounts and personal data stay inside the perimeter.
Does a receipt prove that the agent acted correctly?
It proves that the action was checked against a rule of a certain revision and that the record was not changed. Whether the rule itself is good, the receipt does not prove: the person who approved the rules answers for them.
Sources
- The institute’s book “Proven Action. Power and Control over AI Agents: Strategy 2027–2035”, Chapter 10 (in Russian): https://isslab.ru/en/book/
- Independent verification protocol: https://isslab.ru/en/book/verification-protocol/
- Open chain verification kit: https://asi5.ru/console/verify/
- OpenTimestamps: https://opentimestamps.org/
- NIST FIPS 180-4, Secure Hash Standard (SHS): https://csrc.nist.gov/pubs/fips/180-4/upd1/final
Checked: 18 October 2026, against the text of the book and the published verification kit.