Explainer
Agents now book, buy, send and change things for people, and when one gets it wrong its logs are usually the only witness. Here is how to make that witness one an outsider will believe.
Dinesh Mendhe, Founder and Chairman, The AI LabNovember 5, 2026
An AI agent that can act can also act wrongly, and the first question afterwards is always what it actually did.
Most teams cannot answer that in a way anyone outside the team will accept. Their records sit in databases they run, and a record its owner can quietly edit is a claim rather than proof. What follows is a sequence any team can start this quarter with tools that already exist, and a plain account of where a shared ledger helps and where it does not.
Disclosure. The AI Lab, which I founded, sells agent observability on the Trust Identity Protocol (TIP), one of the approaches described below. Every other step works without it.
Agents Turn Wrong Answers Into Wrong Actions #
A chatbot that gets something wrong produces a bad answer, and a person decides what to do with it. An agent that gets something wrong refunds the wrong customer, emails the wrong supplier or deletes the wrong record, often before anyone looks. The OWASP Top 10 for large language model applications names two failures that make this worse. Prompt injection is when instructions hidden in content the agent reads steer what it does. Excessive agency is when an agent holds more power than its task needs.
When something goes wrong, the people affected ask three things. Which agent did it, on whose authority, and has the record been touched since? Ordinary logs answer the first two for the people who run the system. They rarely answer the third for anyone else.
Record Every Action, Not Just Every Run #
Start by writing down each step, not just each request. For every action, record the time, the agent and its version, the model and prompt version it ran, the tool it called, the input it received, the output it produced and the user it acted for. Give every run and every step an ID that travels with the task, so a job handed from one agent to another can still be followed.
Use the field names the industry is settling on. The OpenTelemetry semantic conventions for generative AI define attributes for model calls, token use and agent operations, so the same trace can be read by different tools and you are not tied to one vendor's format. Keep the full data where your privacy rules allow. Everywhere else, keep a fingerprint of it, a short code computed from the data that changes if a single character changes. A fingerprint lets you prove later that the data you hold is the data the agent saw, without storing or sharing the data itself.
Keep People's Approvals Apart From the Agent's Actions #
For any step that is costly or hard to undo, such as a refund above a limit, a payment or a message to an outside party, route it to a person and record the approval as its own entry. Write down who approved it and when, separately from what the agent did. When an incident review asks whether a person signed off, the answer should be a record, not a recollection. A record its owner can quietly edit is a claim rather than proof.
Make the Record Tamper-Evident #
No log can be made impossible to change, because whoever holds a copy can edit it. The achievable goal is tamper evidence, meaning any change shows. Four techniques get you there, and they combine well.
- Write-once storage. Services such asAmazon S3 Object Lock block edits and deletes for a retention period you set. They protect against accidents and most insiders, inside one provider's account.
- Hash chaining. Each entry includes a hash of the one before it, so removing or reordering a step breaks the chain from that point on.
- Trusted timestamps. A timestamp authority working underRFC 3161 signs a hash of your entry, proving the entry existed at that moment.
- Signatures at the source. The agent signs each entry with its own key when it acts, so an entry cannot be forged later without that key.
Certificate Transparency, the public logs browsers use to catch wrongly issued web certificates, shows what these ideas achieve together at internet scale. Its current design is published as RFC 9162.
Let Someone Outside Check It #
Every technique above still leaves one weakness. The organization that runs the agent also runs the account, the keys and the storage, so an auditor checking the trail is still trusting the party being audited. The fix is to keep the proof somewhere that party does not control alone.
This is where TIP fits, and the disclosure above applies. Agent observability on TIP records each agent action as a signed entry on a shared network of nodes. Each entry names the verified organization responsible for the agent, the agent and its version, and the time, carries a fingerprint of the input and output, and links to the step before it. Only the fingerprint goes on the network. A person's approval is signed separately with their own fingerprint or Face ID. Signatures use ML-DSA-65, the post-quantum standard NIST published as FIPS 204 in 2024. An auditor, regulator or customer you choose can then check any step against the network without access to your systems.
Other designs reach the same goal, such as running your own public transparency log or anchoring hashes with an independent timestamp authority. What matters is the property, not the vendor. The person checking should not have to trust the person being checked.
The Law Is Starting to Ask for This #
Under the EU AI Act, Article 12 requires high-risk AI systems to record events automatically over their lifetime, and Articles 19 and 26 require providers and deployers to keep those logs for at least six months. Many agents will not be high-risk, but those used in hiring, credit decisions, essential services or education can be. The Act does not prescribe a technology, so the burden of showing that logs can be relied on falls on whoever keeps them. There is more on this in EU AI Act logging rules for AI agents.
What This Does Not Solve #
A record shows what happened. It does not stop an attack, and it does not prove the agent's decision was right. Those remain the job of narrow permissions, input filtering, spending limits and human review, covered in AI agent security.
A fingerprint proves a match only against data you still hold. If you delete the raw data, you can prove a step happened and when, but not show what was in it. Decide retention before you need it.
A signature is only as safe as its key. If an agent's key is stolen, the attacker can sign as that agent until the key is revoked, so keys belong in hardware or a managed key service, with a tested way to revoke them.
And recording every step has a cost, in storage, in signing and in the checks people run later. Plan for the volume before an agent starts working at scale.
What to Do This Quarter #
- List every agent you run, what it can touch and who answers for it.
- Record every action with the fields above, using OpenTelemetry names, and give each task one ID. See how to track what your AI agents do .
- Route costly or irreversible steps to a person, and record the approval separately.
- Make the record tamper-evident, starting with write-once storage and hash chaining. See AI agent audit trails you can prove .
- Put the proof somewhere an outsider can check without trusting you, whether a public log you run, a timestamp authority or a shared ledger such as TIP.
The test is simple. If one of your agents made an expensive mistake tomorrow, could someone outside your company confirm what it did without taking your word for it? If not, start with step one.
Dinesh Mendhe is founder and chairman of The AI Lab, which builds the Trust Identity Protocol and sells agent observability on it. This article was drafted with AI assistance and edited by a person. More on how TIP records agent actions at theailab.org/agent-observability.