banner

Audit and Receipts

Every action KOGENT executes produces a signed receipt. Receipts chain together into a tamper-evident audit trail that can be verified without any on-chain interaction.

Receipt chaining

Verification does not produce isolated receipts. Each receipt includes a hash of the previous receipt issued by the same agent, forming a cryptographic chain. If any receipt is deleted or altered, the chain breaks: the hash in the next receipt no longer matches. A verifier can walk backward through the chain and detect any gap or tampering.

Receipt structure

Each receipt contains:

  • Receipt ID. Derived from the call counter and agent address. Globally unique without coordination.
  • Previous hash. SHA-256 of the preceding receipt's canonical representation. The first receipt in a chain uses a zero hash.
  • Action record. Action type, input hash, output hash, and outcome (approved or blocked).
  • Signed timestamp. From the execution context, not the local clock.
  • Agent signature. EIP-191 signature over the entire receipt using the agent's secp256k1 key.

Verifying the chain

A verifier checking the chain:

  1. Fetches the latest receipt
  2. Verifies the agent signature over the receipt content
  3. Fetches the previous receipt, verifies its hash matches the previous_hash field
  4. Repeats until the genesis receipt (which has a zero previous_hash)

Any break in the chain (a missing receipt, an altered field, a hash mismatch) is immediately detectable.

Local by default

The chain is local. It stays on the agent's machine until exported. The cryptographic integrity guarantees are equivalent to an on-chain structure - each link is a hash commitment over its predecessor, but no data is published unless explicitly triggered by the operator.

When exporting for audit, the receipt chain can be anchored on-chain by committing the latest receipt hash to a smart contract. The full chain stays off-chain; only the root hash is published. A verifier can then confirm any individual receipt by walking the chain locally and checking that it leads to the published root.

Blocked action receipts

Receipts are optionally issuable for blocked actions - cases where Rules prevented execution. A blocked receipt records that a policy violation was detected and stopped, without recording what the agent attempted to do. This is useful for compliance audits where regulators want evidence that out-of-policy actions were caught, not just that no violations occurred.