Research
AI Agent Audit Trail: What Auditors Can Check Themselves
November 9, 2026
8 mins read
An AI agent audit trail records what an agent read, decided and did. In finance it becomes evidence when an outside party can check it, data included.
An AI agent audit trail is the record of what an agent saw, decided and did, kept so that someone else can check it later. In finance, a log the operator writes and stores is a starting point. The trail becomes evidence when an auditor, a regulator or a counterparty can check both the record and the data the agent acted on, without relying on the operator's own systems and without seeing the raw data.
Bank supervisors are already asking about this. On 4 November 2026 the US Office of the Comptroller of the Currency (OCC) published Bulletin 2026-54, a framework its examiners use to review how banks use AI, including AI agents. The OCC now uses "super intelligence" (SI) for what it used to call artificial intelligence, and the bulletin says "control intensity could increase with the potential consequences of an SI agent's failure or misuse". An agent that moves money sits at the high end of that scale, and after a bad outcome the first question is what the agent knew when it acted.
What an AI agent audit trail has to hold
A useful trail answers five questions about every action: who the agent was, what it was told to do, which data it read, what it did and what came of it. Payment networks are already building parts of this. Mastercard describes its Verifiable Intent work as "a tamper-resistant record of what a user authorised" that links identity, intent and action, so a dispute can be traced back to the user's instruction (Mastercard newsroom, March 2026). Identity registries and Know Your Agent programs (the agent version of KYC) cover who the agent is; our post on AI agent identity in finance looks at that layer.
The data read is the part that usually stays inside the operator's systems, and it is often the part a dispute turns on. An agent that bought the right asset at the wrong price, or approved a loan on an old balance, followed its instructions. The question is what data it saw.
Why finance asks for more than a log
Logs are not new to banks. What changes with agents is the volume of decisions and the distance between the person who gave the instruction and the system that acted. Safeguards for Agentic Finance at Runtime (SAFR), an industry white paper convened by the Monetary Authority of Singapore (version 1.1, October 2026), proposes a "tamper-evident, append-only record of every governance decision" and says what an agent reports about itself "should not be treated as self-verifying".
For a compliance lead, this turns into a practical test. If an examiner or a counterparty asks why an agent acted, can the team show a record that someone outside the team can check? And can that record show the data behind the decision without handing over customer files or trading positions?
Tamper-evident is not the same as checkable by someone else
Many agent platforms already protect their logs, for example by hash-chaining (each entry carries a fingerprint of the one before it) or by signing entries, so any later edit shows up. That answers one question well: was the log changed after it was written?
It leaves two questions open. First, the chain and the keys still sit with the operator, so an outside checker works from what the operator hands over. That is the same position an auditor is in with any internal system; a check a third party can run on its own adds evidence next to the audit, as our post on cryptographic proof next to attestation (an accountant's report on the numbers) shows for reserves. Second, a protected log of actions says nothing about the data the agent read. The log can show that the agent called a balance service at 10:02. It cannot show which balance came back, or that the database had not been changed between that call and the audit.
A proof-backed record lets an auditor check both the action and the data behind it on their own.How do AI agents verify the data they use?
Many AI agents do not verify their data today: they trust whatever a tool, an API or a retrieval system returns. Real verification means the agent, or a policy in front of it (the code that decides whether the agent may act), checks a proof that the data was stored and processed as claimed before it acts.
The rest of the agent stack does not cover this. ERC-8004, a draft Ethereum standard, gives agents on-chain registries for identity, reputation and validation, and its own security notes say a registration "cannot cryptographically guarantee that advertised capabilities are functional and non-malicious". Intent records, covered in our post on verifiable intent, show what the user authorised. None of these layers proves which data the agent read when it decided, so a decision cannot be replayed months later against the same data.
Can an AI agent prove its data without exposing it?
Yes, if the data sits in a system that produces a proof for each read and write. A Zero-Knowledge Proof (ZKP) lets one party show that a statement about private data holds without revealing the data itself.
Take an agent that checks a customer's balance at 10:02 before it approves a payment. The team shows the auditor the one value the agent used and a proof that this value came from the database exactly as it stood at 10:02, a state that was fixed and published on-chain at the time. The auditor checks the proof. They see the value that mattered and confirm it was not changed afterwards; they do not see the customer's other data or anyone else's account. The proof does not say whether the balance itself was right at the source, only that the agent read what the database held.
A provable AI agent audit trail in five steps
zkDatabase, the verifiable database built by Orochi Network, generates a ZKP for every insert, update and query. Here is how that turns an agent's actions into a trail an outside party can check.
- Write the data with a proof. Each update to the data the agent will use (balances, limits, eligibility lists, prices received from a provider) comes with a proof that the change was made correctly. The database state is then committed: a short fingerprint of the whole data set, called a Merkle root, is published on-chain, so any later change shows up.
- Query with a verifiable result. When the agent asks for data, zkDatabase returns the result with a proof that it matches the committed root. The agent's policy, or a smart contract, checks the proof before the agent acts.
- Record the action next to its proof. The action record stores which proof and which committed state the agent used, and when. The trail now links the action to the exact data version behind it.
- Let the auditor check on their own. An auditor, a regulator or a counterparty checks the proof against the committed root. They do not need the raw data and do not need access to the operator's systems.
- Replay the decision later. In a dispute or an exam months later, the team points to the committed state the agent read and shows the decision against it, instead of rebuilding the past from logs.
The proof covers how the data was stored and processed. It does not show that a price from an outside provider was right or that the agent's decision was a good one; those stay with the data provider, the model and the people who set the agent's limits. What the proof adds is that nobody has to take anyone's word for what the agent saw.
zkML and zkDatabase cover two halves of the evidence
A full account of an agent decision has two halves: the model that reasoned and the data it reasoned on. zkML, which proves that a given model produced a given output, covers the first half; our benchmark of zkML frameworks compares the main approaches. zkDatabase covers the second half by proving the data the model used. A trail that holds both lets a reviewer check the decision without trusting either side's say-so.
See how zkDatabase proves what an agent read
Explore how zkDatabase attaches a proof to every read and write, so an auditor can check an agent's data without seeing it.
Related toResearch
