Deep diveAI Studio
What a verifiable audit trail for AI agent actions should contain
Autonomous agents take decisions someone will later have to reconstruct: which task, model and prompt version, tools and inputs, whose approval and what happened. This page defines the fields of an agent action record, separates what stays in your own store from what is worth anchoring on Hedera Consensus Service, maps the design to EU AI Act record-keeping and the NIST AI RMF, and states what a ledger receipt cannot prove.
On this page
- Where ordinary application logs fall short for agents
- Anatomy of an agent action record
- What stays in your store and what goes on the ledger
- Privacy by design for agent records
- Anchoring pattern: capture, hash, batch, submit
- Record-keeping duties that shape the design
- How an auditor or counterparty checks a record
- Agents that deal with other organisations' agents
- What a ledger receipt proves, and what it does not
- Questions and answers
- Sources
Where ordinary application logs fall short for agents
Application logs answer operational questions: did the request succeed, how long did it take, which service failed. An agent raises different ones. Why did it pick this supplier? Which prompt version was live? Did a person approve the payment, or did the agent decide alone? The answers are usually scattered across a model provider's console, the orchestration framework, an approval tool and the ledger, each with its own retention and access rules.
Logs are also editable by the team that runs the system: fine for debugging, weak in a dispute. A counterparty, auditor or regulator relying on a record needs to know it has not changed since the event, without taking the operator's word for it.
Anatomy of an agent action record
One record per consequential action. These fields are a minimum; regulated sectors add their own on top.
- Task and principal
- The task identifier, who or what assigned it, and the authority under which the agent acted, such as a delegation or a named service account.
- Model and prompt version
- Model provider and version, the system prompt's version or hash, and settings that change behaviour, such as the enabled tool list.
- Tool calls
- Each call in order, with tool name, parameters, result status and timing, including failed or refused calls.
- Inputs by digest
- Salted digests of the documents, messages and retrieved passages the agent relied on, with pointers to where the originals are held.
- Policy decisions and approvals
- What the policy layer allowed or refused and why, plus the identity of any human approver and when they approved.
- Outcome
- The final result, including ledger transaction IDs and receipts where value moved, and any error or escalation.
- Anchor reference
- The digest of the canonical record and, once anchored, the topic ID and sequence number of the message that covers it.
What stays in your store and what goes on the ledger
Ledger data is public and permanent, so the default is that nothing readable goes on-chain.
| Record element | Your record store | Hedera Consensus Service anchor |
|---|---|---|
| Task, principal and timestamps | Full values, access-controlled | Covered by the batch digest only |
| Prompts, documents and retrieved passages | Originals or pointers, under your retention rules | Never in clear; covered by salted digests |
| Model and prompt versions | Full identifiers | Covered by the digest; publish a version hash separately only if counterparties need it |
| Approvals | Approver identity and signature | Covered by the digest |
| Value transfers | Transaction IDs and receipts | Already on the network; referenced by ID, not repeated |
| Batch root | Stored with the list of records it covers and each record's proof | Submitted as the topic message |
Anchoring one root per batch, rather than one message per action, hides per-action timing and keeps fees predictable.
Privacy by design for agent records
Decide what could identify a person before the first record is written; retrofitting redaction rarely works.
Anchoring pattern: capture, hash, batch, submit
Keep this step simple. Topic design and alternatives to ledger anchoring are covered on the Hedera Consensus Service pages.
- Capture record
The policy layer writes one canonical record per consequential action.
- Canonicalise and hash
Fields are serialised in a fixed order and given a salted digest.
- Build batch root
Digests for a period are combined into a Merkle root, keeping each record's proof.
- Submit to topic
The root is sent as a topic message, signed with the topic's submit key.
- Store the receipt
The sequence number and running hash returned in the receipt are saved with the batch3.
- Verify on demand
Anyone holding a record and its proof can check it against the message on a mirror node.
Record-keeping duties that shape the design
Duties depend on your role and whether the system is high-risk. Wider deployer duties are covered in EU AI Act deployer obligations.
EU AI Act (Regulation (EU) 2024/1689), Article 12
European UnionApplies whenYou provide a high-risk AI system, including one built on an agent framework.
EU AI Act (Regulation (EU) 2024/1689), Article 19 and Article 26
European UnionApplies whenYou are the provider or deployer of a high-risk AI system and the logs are under your control.
NIST AI Risk Management Framework (NIST AI 100-1)
United States (voluntary)Applies whenYou structure AI risk management around the framework, or a customer expects alignment with it.
- Practice is organised into four functions: Govern, Map, Measure and Manage4.
- Traceable records of what an AI system did are the practical evidence for measuring and managing its risks.
How an auditor or counterparty checks a record
Obtain the record and its proof
The operator supplies the canonical record, the salt or key to recompute its digest, and the Merkle proof linking it to a batch root.
Recompute the digest
The verifier serialises the record in the documented canonical form and confirms the digest matches.
Rebuild the batch root
Applying the proof to the digest must produce the root the operator says was anchored.
Find the message on a mirror node
Look up the topic ID and sequence number. The message must equal the root, and its consensus timestamp shows when it was recorded.
Check approvals and transfers
Verify approver signatures against known keys and confirm referenced transactions show the expected accounts and amounts.
Write down the limits of the check
Note what was verified and what was not, such as the content of documents held only as digests.
Agents that deal with other organisations' agents
When an agent negotiates with, pays or hands work to an agent run by another company, neither side can rely on the other's internal logs. Each should record its own view and anchor its digests to a topic both can read, giving a shared, ordered timeline without sharing raw records.
Hedera's OpenConvAI standard (HCS-10) defines how agents discover each other and exchange messages over consensus topics5. Where a conversation runs over it, the messages are already ordered and timestamped, so your record should cite their sequence numbers rather than copy their content.
What a ledger receipt proves, and what it does not
Questions and answers
Do agent audit trails need a ledger at all?
Not always. If only your staff and auditors who accept your controls will read the records, a write-once store with strict access and independent backups may be enough. A ledger anchor adds value when parties outside your control, such as counterparties, regulators or a court, must verify records without trusting your systems, or when several organisations need one ordered timeline.
How long should AI agent logs be kept?
Set retention per record type. Under the EU AI Act, deployers of high-risk systems keep the automatically generated logs under their control for a period appropriate to the intended purpose and at least six months, unless other law, such as data protection law, says otherwise1. Finance or health rules may require longer. Anchored digests stay on the ledger regardless; what you retain or delete is the off-ledger record.
Can we anchor records without revealing how much our agents do?
Largely. Anchor one Merkle root per fixed interval rather than one message per action, and submit on schedule even when a batch is small or empty, so message count and timing reveal little about volume. A dedicated topic for anchors helps further. Transactions that move value remain visible on the network, so this protects the records, not the payments themselves.
Who should own the agent record: the model provider, the framework or us?
You should. Provider consoles and framework traces are useful sources, but someone else sets their retention, format and access. Capture the record in your policy or orchestration layer, in a schema you control, and pull provider and framework identifiers into it, so a change of model or framework leaves your evidence intact.
Sources
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (Artificial Intelligence Act), Articles 12, 19 and 26 — EUR-Lex · checked 10 October 2026
- Regulation (EU) 2026/1744 amending Regulation (EU) 2024/1689 as regards the simplification of the implementation of harmonised rules on artificial intelligence (Digital Omnibus on AI) — EUR-Lex · checked 10 October 2026
- Submit a message to a topic — Hedera documentation · checked 10 October 2026
- AI Risk Management Framework (NIST AI 100-1) — National Institute of Standards and Technology · checked 10 October 2026
- Introducing Hedera AI Studio — Hedera · checked 10 October 2026