Arcezia / AI agent security / Audit evidence

AI agent audit evidence: signed records you can check yourself

AI agent audit evidence is a record, made before an agent’s tool call runs, of what was decided and why, kept so that a later change shows. Arcezia keeps one signed execution record per check: the answer (ALLOW, REVIEW or BLOCK), its reason, the tool and session, signed with Ed25519 and linked to the record before it. An auditor checks the records offline with an open-source checker, without trusting Arcezia or the account holder. Below is a real four-record export from Arcezia’s own test account, the account’s key fingerprint, the command, and the output it gave.

Check the sample yourself

File

sample-export.ndjson (19,676 bytes, a signed header line and 4 records)

SHA-256

8652f83b4eacc4a4e90c10c2f8812652928a0959046f347265de876a92783481

Exported

7 October 2026, 10:21:08 UTC, from Arcezia’s self-test account (account 26), unedited

Record-signing key fingerprint

4c5e576d5765a7334c9d1a34bef62084627b66206d2018dff957987717c3c15c

Records 13100 to 13102 are the three answers on the action authorization page, from its raw HTTP run: the same call, allowed, held and refused. Record 13099 is the record just before them, from another test on the same account. It is there so that the three records’ links can be checked.

Run:

pip install "arcezia[verify]"
curl -sO https://arcezia.com/audit-evidence/sample-export.ndjson
arcezia-verify-records sample-export.ndjson --use-export-keys --partial \
    --fingerprint 4c5e576d5765a7334c9d1a34bef62084627b66206d2018dff957987717c3c15c

The fingerprint is printed on this page, apart from the file, which is the point: the key decides everything, so it must not come only from the file being checked. For your own records, read it from the dashboard’s API Keys page (“Record-signing key fingerprint”) or from GET /v1/account/record_keys, and give it to your auditor yourself.

Expected output (measured with arcezia 1.0.7; exit status 2):

account        : 26
keys           : 1 key(s) matched a fingerprint supplied out of band (keys read from the export)
  key 4c5e576d5765a733  sha256 4c5e576d5765a7334c9d1a34bef62084627b66206d2018dff957987717c3c15c  (compare with the account holder's)
records        : 4
times shown    : the signed time inside each record; the export's plain 'timestamp' column is not covered by the signature

  record    13099  UNVERIFIED  signed 2026-10-07T10:19:36.331792+00:00  verdict BLOCK
                      - the first record here follows records not in this export (partial export)
  record    13100  PASS        signed 2026-10-07T10:19:37.338602+00:00  verdict ALLOW
  record    13101  PASS        signed 2026-10-07T10:19:39.011984+00:00  verdict REVIEW
  record    13102  PASS        signed 2026-10-07T10:19:40.743972+00:00  verdict BLOCK

export headers:
  sample-export.ndjson  PASS        header signature matches and agrees with the file

checkpoints (carried inside the export):
  checkpoint    22  PASS        up to record 13102, 2864 record(s), as of 2026-10-07T10:19:50.461882+00:00: signature matches
  checkpoint    21  PASS        up to record 13001, 2774 record(s), as of 2026-10-07T09:53:20.289230+00:00: signature matches
  checkpoint    20  PASS        up to record 13000, 2773 record(s), as of 2026-10-07T09:53:18.369772+00:00: signature matches
  checkpoint    19  PASS        up to record 12941, 2714 record(s), as of 2026-10-07T03:13:25.916291+00:00: signature matches
  checkpoint    18  PASS        up to record 12500, 2467 record(s), as of 2026-09-20T19:05:05.696928+00:00: signature matches
  checkpoint    17  PASS        up to record 12000, 2052 record(s), as of 2026-09-16T20:45:49.349811+00:00: signature matches
  checkpoint    16  PASS        up to record 11500, 1636 record(s), as of 2026-09-16T19:16:26.565572+00:00: signature matches
  checkpoint    14  PASS        up to record 10863, 1273 record(s), as of 2026-09-12T11:28:35.306509+00:00: signature matches
  checkpoint    13  PASS        up to record 10863, 1273 record(s), as of 2026-09-12T11:28:27.678777+00:00: signature matches
  checkpoint    12  PASS        up to record 10769, 1179 record(s), as of 2026-09-12T11:17:11.490864+00:00: signature matches
  checkpoint    11  PASS        up to record 10769, 1179 record(s), as of 2026-09-12T11:17:05.970650+00:00: signature matches
  checkpoint    10  PASS        up to record 10717, 1127 record(s), as of 2026-09-12T11:15:47.888685+00:00: signature matches
  checkpoint     9  PASS        up to record 10717, 1127 record(s), as of 2026-09-12T11:15:42.562457+00:00: signature matches
  checkpoint     8  PASS        up to record 10614, 1059 record(s), as of 2026-09-11T10:10:54.502046+00:00: signature matches
  checkpoint     7  PASS        up to record 10614, 1059 record(s), as of 2026-09-11T10:10:47.853331+00:00: signature matches
  checkpoint     6  PASS        up to record 10500, 972 record(s), as of 2026-09-11T09:59:48.253208+00:00: signature matches
  checkpoint     4  PASS        up to record 9500, 694 record(s), as of 2026-09-07T17:04:14.502500+00:00: signature matches
  checkpoint     3  PASS        up to record 9065, 341 record(s), as of 2026-09-07T09:45:12.593718+00:00: signature matches
  checkpoint     2  PASS        up to record 9065, 341 record(s), as of 2026-09-07T09:45:05.375206+00:00: signature matches
  checkpoint     1  PASS        up to record 9000, 323 record(s), as of 2026-09-07T09:39:46.687967+00:00: signature matches

completeness   : PASS  the export reaches record 13102, at or beyond the strongest signed checkpoint (record 13102, carried inside the export)
                 (these checkpoints travelled inside the export; one kept outside Arcezia (--checkpoint) is stronger evidence)

PASS 3   PASS-ATTESTED 0   FAIL 0   UNVERIFIED 1
RESULT         : UNVERIFIED

Three records PASS. Record 13099 is UNVERIFIED: it follows records that are not in this file, so its link backwards cannot be checked, and the checker will not vouch for what it cannot see. The export reaches the newest signed checkpoint in its header (record 13102), so nothing is missing from the end.

Leave out --partial and the same file FAILs (exit status 1): record 13099 gets the first record follows a record that is not here, and no signed removal statement accounts for it, and completeness gets FAIL the signed checkpoint counted 2864 records up to record 13102; with 0 removed under signed statements, at least 2864 should be here, and 4 are. That is the checker doing its job: an excerpt is missing records, unless you say it is an excerpt. An auditor asks for the complete export, every page from the account’s first record, and runs it without --partial.

What each result means

• PASS: every check that applies to the record succeeded: the signature, the plain columns against the signed content, the account, and the link to the record before.
• PASS-ATTESTED: a record signed before the current public record format. Its original signed bytes are not in the export, so its place in the sequence is proven by the links to a signed checkpoint, and its content is vouched for by a current signed statement. You are trusting that statement for the content; it is not the same as PASS.
• UNVERIFIED: nothing contradicts the record, but something needed to confirm it is missing: the key, the record before it, an erasure statement.
• FAIL: a contradiction: content changed, a signature that does not match, a record missing between two others, a column edited.

Exit status 0 means every record is PASS or PASS-ATTESTED and the export is complete; 1 means at least one FAIL; 2 means no FAIL but something is UNVERIFIED or completeness is unknown; 3 means the input could not be read.

Signed execution records: what one record holds

• The answer, and its reason labels (BLOCK) or release labels (REVIEW), as returned to the caller.
• The tool name, the domain, the session and request ids, the account, and the time it was signed.
• A digest of the action, not its content.
• When a person’s approval was attached: its one-time id, its role, the fingerprint of the approval key that verified it, the call it was bound to, and whether it counted. Not the person’s name.
• An Ed25519 signature over all of it, and the hash of the record before it. Each export page has a signed header, and signed checkpoints state how far the records reached at a time.

When an account is deleted, record content is erased and only hashes remain. The deletion returns a receipt; with it the account holder fetches signed erasure statements, and the checker (--erasure) confirms each erased record was erased, not altered.

What the records do not show

• Calls that were never checked. A record exists only for a call sent for a check. Showing that every executed action had one means matching your own execution logs against the records.
• What happened when the tool ran. ALLOW means the call was permitted, not what it did.
• Whether an answer was right. The checker shows the records are genuine, ordered and complete. It does not grade the decisions.
• Who the approver was. Your approval system maps the approval id to the person.

For auditors in regulated sectors

Each sector page maps the records to the rules that ask for logs, oversight or tamper evidence, with sources, and comes with a step-by-step audit procedure: banks and financial services (procedure) and healthcare (procedure). Record format and export settings: developer docs, receipts and compliance.

Related

• AI agent security: the model, the data, and what the agent does
• Action authorization: one tool call, three answers
• Glossary: signed decision record