Ask an engineering team what their AI agent did yesterday and they will open a log. Ask an auditor whether they would sign off on what it did, and the log stops being enough. The two questions sound alike. They are not.
A log is written for the people who built the system, to help them debug it. It records that something happened, in their vocabulary, with their identifiers. Proof is written for someone who was not there, does not trust the people who were, and has to put their name to a conclusion. It has to answer different questions, and it has to answer them in a way that cannot be quietly rewritten afterwards.
As agents move from answering questions to taking actions, raising invoices, changing records, calling customers, that difference starts to matter. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, and weak risk controls are one of the three reasons it gives. "We have logs" is rarely the control a risk committee is looking for.
Five questions an auditor asks
When an agent does something that matters, the person reviewing it later wants to know five things.
- What happened? Which action, on which record, with what result.
- Why was it allowed? Not "the model decided to", but which rule permitted it, as that rule was written at the time.
- Who said yes? If a person approved it, who they were, when they decided and what they wrote.
- On whose behalf, and where? Which agent acted, for which person, in which conversation or run.
- Can I trust this account? Is the record complete, and would I know if someone had edited it?
A typical agent log answers the first question, partly. It shows a tool name, some arguments cut off at a hundred characters, a timestamp and a run identifier. The other four are either missing or need an engineer to reconstruct them from three other systems.
What a proof record holds
In Camaan, every governed action, whether a tool call in a chat, a step in a workflow or a change to a setting, produces one signed record. Here is what is in it, and which question each part answers.
| Field | What it says | Answers |
|---|---|---|
| The action | The tool or step, the resource it touched, the outcome | What happened |
| The decision | Allowed, asked first or denied, the kind of rule, and the rule in words, such as "execute actions ask before running for this agent" | Why it was allowed |
| Deciding policies | The access policies that decided it, named as they were at the time, for allowed actions as well as refusals | Why it was allowed |
| The approval | The person's answer (approved, declined, sent back, lapsed), who, when, and their comment, signed with the record | Who said yes |
| Session and agent | The conversation or run, the agent that acted, and who it acted for | On whose behalf |
| The payload | The whole canonical payload, kept byte for byte as it was hashed | Can I trust it |
| Signature and chain | An Ed25519 signature, the hash of the previous record, and an hourly Merkle window | Can I trust it |
Two details in that table are easy to miss and matter a great deal.
First, the rule is recorded for actions that were allowed, not only for those that were refused. Most systems are good at explaining a "no". An auditor is far more interested in the "yes": the payment that went out, the record that was changed. If you can only show why things were blocked, you cannot show why the things that happened were permitted.
Second, the payload is kept exactly as it was hashed. A hash is only useful if you can recompute it. Keeping a hash and a 120-character preview, as many ledgers do, means the hash proves nothing about what the action actually contained. Keeping the canonical bytes means Verify can re-hash them and compare.
Proof belongs where the work happened
A ledger that only an auditor ever opens will not change how people work. The decision has to be visible to the person using the agent, at the moment it matters.
So in a Camaan chat, every tool call carries one readable line under the reply:
These lines are not a summary written by the model. They are the same decision the signed record holds, carried from the agent loop to the screen and stored with the conversation, so they read the same after a reload. "View signed record" opens that exact action's record, and the person who owns the conversation can open it without needing an auditor's role.
A refusal is also recorded as a refusal. That sounds obvious, but in most agent frameworks a denied call is stored as a tool error, indistinguishable from a timeout. When the record says "denied", the history says "denied" too.
Names, not identifiers
The fastest way to make an audit trail useless to an auditor is to fill it with identifiers. "Tool 3f9a… invoked by user 77c1… in session b204…" is accurate and unreadable. The reviewer has to look up every one, and each lookup is a chance to get it wrong.
Our rule is simple: names on screen, identifiers one hover away. Records, approvals and run histories show people, agents, sessions, policies and reports by name. Hover, or press Enter, and the identifier appears with a copy button for anyone who needs to trace it. Something that has since been deleted keeps its last known name. Something the reader is not allowed to see says "an agent you can't view", without leaking what it is called.
Store the identifier. Show the name. An auditor should never have to decode a record to read it.
Who may read the proof
Proof can itself be sensitive. A record of who approved a payment to whom is exactly the kind of thing that should not be readable across organisations. In Camaan, an organisation's administrators read only their own organisation's records; only the platform operator reads across them. And the person who started a conversation can open the records of their own actions in it, without being granted the auditor's view of everything else. Test these boundaries with the same rigour as the actions the records describe.
Checking the story
The last question, "can I trust this account", is answered by Verify. On any record it re-checks three things against the live ledger: the signature, the hash chain back to the previous record, and the record's place in its hourly Merkle window. A record that was altered fails. A record that was removed leaves a gap in the chain that the integrity check reports.
Around the record, the same ledger feeds the other places an auditor looks: the approval queue, where an agent running on a schedule files a request and a second person decides; a session's Explain, which writes an account of what happened where every claim cites the steps behind it; and reports built straight from the ledger, exported as PDF or Word, or poured into your firm's own template.
What we are still building
Two things are next. Today the record shows what an agent did and why it was permitted; it does not yet keep the agent's plan and reasoning with each message, so you cannot always see what it intended. And today Verify runs inside Camaan. We are building an evidence pack, the records, the keys and the proofs in one package, with a standalone checker an auditor can run without us. Proof that depends on the vendor's word is better than a log, but not as good as proof that depends on nobody's.
A test for your own agents: pick one action an agent took last week and ask someone outside the team to answer the five questions from the record alone. If they need an engineer, you have logs, not proof.
Sources: Gartner, "Gartner Predicts Over 40% of Agentic AI Projects Will Be Canceled by End of 2027", 25 June 2025. Product details describe Camaan as of November 2026.