Verified agent audit trail: proof of correct work

Most pages about agent audit trails are about permission. They log who the agent was, what it was entitled to touch, and whether the policy engine said yes. That is real work and it does not answer the question a regulator or a controller actually asks, which is whether the agent got the job right.

What is a verified agent audit trail?

A verified agent audit trail is a record of an agent's run in which every step carries both the action taken and the verdict of a check that was approved before the run started. A conventional audit trail records the action. A verified one records the action and the grade. The difference is the difference between "the agent posted this journal entry and was allowed to" and "the agent posted this journal entry and the three-way match passed at step 6".

Put the two side by side: an entitlement log proves the agent was allowed to act, a graded run proves it acted correctly. You need both, and the market only sells one of them.

What does an entitlement log prove?

An entitlement log proves authorization, which means it answers whether an action was permitted by policy and by whom it was permitted, and nothing about whether the action was right. The governance vendors are explicit about this framing. Collibra defines an AI audit trail as "a chronological, traceable log of every consequential event in an AI system's operation, captured in enough detail to reconstruct what happened and prove it later", and lists the four questions it should answer: "what data went in", "what came out", "what the system did with it", and "whether it was allowed" (AI audit trails: what to log for models and agents).

Three of those four are answerable by instrumenting the pipeline. The fourth, "whether it was allowed", is a policy lookup. None of them is "whether it was correct", because correctness is not a property of the log. It is a property of your process, and somebody has to write it down before the run.

The runtime-security version has the same shape. ARMO's minimum viable audit trail is about capturing agent activity from the infrastructure side so security teams can reconstruct behavior. Good engineering, aimed at a different failure. An agent that exfiltrates data is a security event. An agent that reconciles an invoice against the wrong purchase order using credentials it was entitled to use is a correctness event, and it will not appear in either log as anything other than a successful action.

Why is logging the agent's reasoning not an audit trail?

Logging the agent's reasoning is not an audit trail because the model's stated reasoning is not a reliable report of the process that produced the output. This is the trap in every "log the decision trace" checklist. The trace reads like an explanation and is not one.

Anthropic measured it directly. Given a hint that changed its answer, "Claude 3.7 Sonnet mentioned the hint 25% of the time, and DeepSeek R1 mentioned it 39% of the time" (Reasoning models don't always say what they think, April 2025). In the setup where models learned to exploit a reward hack, "the models very rarely admitted to using the reward hacks in their Chain-of-Thought explanations, doing so less than 2% of the time". An audit trail built on self-reported reasoning is at its weakest precisely where you need it, which is when the agent did something it should not have.

An approved check does not ask the agent anything. It reads the state of the systems the agent touched and decides. That is why the verdict belongs in the record and the narrative does not, or at least does not stand alone.

What does the EU AI Act require by August 2026?

The EU AI Act requires providers of high-risk AI systems to keep automatically generated logs for "a period appropriate to the intended purpose of the high-risk AI system, of at least six months" (Article 19), and that obligation becomes applicable on 2 August 2026. Longer retention applies where other Union or national law requires it, and financial institutions keep the logs as part of their existing documentation duties.

Six months of logs is a storage requirement. The interesting part is what has to be in them. Article 19 sits on top of the recording obligation for high-risk systems, which is what an IETF individual submission, Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems (Raza Sharif, submitted 29 March 2026), is written against. That draft proposes a JSON record with mandatory record_id, timestamp, agent_id, agent_version, session_id, action_type, action_detail, outcome, and trust_level fields, chained by prev_hash so that "unauthorized modification" is detectable.

Note what the schema carries and what it does not. outcome classifies the result as success, failure, timeout, denied, or escalated. That is the agent's own report of how its action terminated. It is not a verdict from an independent check on the resulting state. A run can be outcome: success and wrong.

What belongs in a verified agent audit trail?

Six fields, and the last two are the ones nobody ships.

1. Step number. The process decomposed into numbered steps before any agent ran it. This is what turns "the agent got it wrong" into "step 4 failed".
2. Action and payload. What the agent did, against which system, with what inputs and outputs.
3. State read back. The state of the affected systems after the step, read independently rather than reported by the agent.
4. Identity and authority. Which agent version, acting on whose behalf, under what authorization. The entitlement layer, kept.
5. The check applied, with its version. The specific pass condition attached to that step, identified by version, so a record from March can be reread against the check that was actually in force in March.
6. The verdict and the check's measured error rate. Pass or fail, plus what kind of check produced it and how reliable that kind is. A computed check is deterministic. A classified or judged check has a holdout score, and the score belongs next to the verdict.

Field 6 is what makes the trail verified rather than descriptive. Without it, a reader of the log knows an assertion passed and has no way to price that assertion.

How does a run record differ from an agent log?

The rows are complementary, not competing. Most buyers have some version of the first two and nothing in the third, which is why postmortems on agent work still end in someone reading a transcript.

Who is building agent audit trails today?

Four groups, working on three different problems.

• Governance and cataloging. Collibra and comparable data-governance platforms treat the trail as the evidence layer of AI governance, wired into policy and lineage. Strongest on completeness and reporting. Silent on correctness.
• Runtime security. ARMO and the agent-security tooling around it capture activity from the infrastructure, which catches behavior no application-level logger sees. Aimed at compromise, not error.
• Identity and provenance. Vouched and Truescreen sign and chain records so each event can be verified independently of the party that produced it. This is the tamper-evidence problem, and it is solved reasonably well. A signed record of a wrong action is a wrong action you can prove nobody edited.
• Standards. The Agent Audit Trail draft is the first serious attempt at a common wire format. Worth tracking, worth adopting as the envelope, and it leaves the verdict field for someone else to fill.

Pebble sits in none of those buckets. We build the environment that produces field 5 and field 6, and we assume you already have or will buy the other three layers. The full disambiguation of what "verification" means across these markets is in agent verification.

How do you get one?

Start by picking one process and writing down the pass condition for each of its steps, because that document is the audit trail's schema and it does not exist yet at most companies. Then decide, per step, whether the condition is decidable by code, by a scored classifier, or by a judge with measured human agreement - the three tiers are defined in approved checks, and the method for grading real runs against them is in how to verify AI agent work. A worked compliance example, with the record shape for regulated intake, is in AI safety report triage. Vocabulary: glossary.

If you want a second opinion on whether your process produces a defensible record, bring one process to a scoping call at [email protected]. If your obligation is really about access control, we will tell you to buy an entitlement product instead.