cd /news/ai-safety/ai-agent-audit-logs-need-12-fields-w… · home topics ai-safety article
[ARTICLE · art-124545] src=pub.towardsai.net ↗ pub= topic=ai-safety verified=true sentiment=↓ negative

AI Agent Audit Logs Need 12 Fields. We Counted 6 Frameworks — the Median Records 5.

A 4 September 2026 audit of six open-source AI agent frameworks found that the median framework records only 5 of the 12 mandatory fields required by the agent audit trail Internet-Draft, and none record tamper-evidence fields. The analysis, which compared tool-call records from openai-agents-python, langchain, crewAI, llama_index, smolagents, and openinference against the draft by Raza Sharif of CyberSecAI, shows that debugging-oriented instrumentation is largely uncorrelated with audit readiness, with fields like non-repudiation and pre-execution missing across all frameworks.

by read7 min views3 publishedSep 9, 2026

An agent calls a tool. Money moves, a row is deleted, an email goes out. Then somebody asks the only question that matters: can you prove what it did?

You open the trace. There is a span, with a name, a start time, an input, an output. It looks like evidence. It is not — it is a debugging artifact shaped like one.

So on 4 September 2026 we counted. We cloned six open-source agent frameworks and instrumentation specs at their current commits, extracted every field their tool-call record carries, and diffed those against the twelve mandatory AI agent audit log fields set out in the newest agent audit trail format.

The median framework records five of the twelve fields an audit record needs, and not one of the six records a tamper-evidence field of any kind.

What agent frameworks record is built for debugging. An audit record has a different job, and the distance between the two turns out to be countable.

Agent frameworks instrument themselves well for debugging and badly for evidence, and the two look alike enough that nobody notices the substitution until somebody asks them to prove something. The missing fields are not obscure: they establish who acted, under what authority, and whether the record has changed since — precisely what a debugging trace has never needed. We counted them framework by framework, so the gap is a number instead of an opinion.

We cloned six repositories on 4 September 2026 and pinned each to its head: openai-agents-python at 89c02c8, langchain at 0d50cbd, crewAI at 92eb5f9, llama_index at d2ac544, smolagents at 30bb116, openinference at 479d168. For each we took the object that records a single tool call — the span envelope plus its tool-specific payload — and extracted every field name by parsing the class definitions rather than reading the docs. Then we mapped those fields onto the twelve mandatory fields of the current audit-trail draft.

Where a field only partly satisfies a requirement we scored it partial and said why. LangChain’s error tells you something failed; it does not separate failure from timeout, denial or escalation.

The reference we used is the agent audit trail Internet-Draft, revision 02, published 3 September 2026 by Raza Sharif of CyberSecAI. It is an individual submission, not an endorsed IETF standard, and we are treating it as one carefully-reasoned proposal rather than settled law. But it is the most concrete published answer to the question, and its twelve mandatory fields are hard to argue with:

Read that list next to a span object and the shape of the problem appears. The first eight are things a debugger would plausibly want. The last four are things only an auditor wants — and those are the four that are missing.

Field counts on the tool-call record, and coverage against the twelve:

Note what field count does not predict. CrewAI records the most fields and still covers fewer requirements than LangChain, because much of its twenty-five is crew context — agent_role, from_task, plan_step_number, delegations — genuinely useful, and answering none of the audit questions. Richness of instrumentation and fitness as evidence are close to uncorrelated.

CrewAI does earn one thing nobody else has. Because it emits ToolUsageStartedEvent and ToolUsageFinishedEvent as separate classes, it is the only framework here with a real record_phase — a record that exists before the tool runs. That matters more than it sounds: a post-hoc-only log cannot prove an action was authorised before it happened, only that it happened.

Four of the twelve are absent across all five frameworks, and two of those are absent across all six including the instrumentation spec:

non_repudiation returns zero files too. So does pre_execution.

Because they were built for a different question. A trace exists so an engineer can find out why something was slow or wrong, and for that input, output, duration and a parent pointer are close to sufficient. Evidence has to survive an adversary — including whoever holds the log — and none of these systems were designed against that threat model. The fields are not missing through oversight; they are missing because nobody asked the trace to be evidence until this year.

Partly, and it is the strongest counter-argument to this piece. OpenInference covers 8 of 12 — the best result in our set — and OpenTelemetry’s GenAI conventions do define gen_ai.agent.id and gen_ai.agent.version, which closes the identity gap on paper. Populated consistently, four of our twelve would be resolved by adoption rather than new work.

But the two hardest stay open. Tamper-evidence is not an attribute you can add to a span, because it is a property of the store, not the record: a hash chain only means something if it is written where the writer cannot rewrite it. And record_phase requires emitting a record before the action runs — an architectural choice about when you write, not a field you append afterwards. Neither is a semantic-conventions problem.

We want to be precise about the limits here, because the number is only useful if its edges are honest.

One thing this cannot settle: whether it matters for your system. If your agent reads documentation and drafts text, a debugging trace is the right artifact and this is over-engineering. The gap only bites when an agent’s actions have consequences somebody might later dispute.

Three things, in the order they pay off.

None of this needs a new framework. It needs about two hundred lines around the one you already use.

This is the same shape as silent agent failures that no dashboard catches — an absence that reads as health because nothing was written down. It is why, when we reproduced the turf war between multiple agents on one codebase, the failures that hurt most were the ones nobody could attribute afterwards. If you are weighing the instrumentation cost, our measurement of what MCP tool definitions cost in context is the other half of that budget.

The opposite case exists: Anthropic’s 13-million-line Fermat proof, where every step is kernel-checked and you can prove what happened.

The next question this raises is what the evidence layer costs to carry. We are measuring that next: the context a bundled agent plugin spends against the same capability wired up as loose MCP servers.

What is the difference between an agent trace and an agent audit log? A trace is written for engineers, to explain behaviour after the fact; it assumes the writer is trustworthy. An audit log is written for a disputing party, and must establish identity, authority and integrity — who acted, under what permission, and whether the record has changed since. The five frameworks average 5 of 12 audit fields while carrying 6 to 25 trace fields each. That is the gap in one sentence.

Can I make LangChain traces audit-ready? Partially, and by building around it rather than configuring it. LangSmith’s RunTree gives you 6 of the 12 directly, including session_id and parent_run_id. You would add agent identity and version, an outcome vocabulary, a trust level, a pre-execution record, and a hash chain in append-only storage. The extra field can carry them; nothing populates them for you.

Does OpenTelemetry solve agent auditability? It closes the identity half. OpenTelemetry’s GenAI conventions define gen_ai.agent.id and gen_ai.agent.version, and OpenInference's mirror of them scored the best coverage in our set at 8 of 12. It does not close tamper-evidence or pre-execution recording, because those are properties of when and where you write, not of what attributes a span carries.

Which agent framework is best for auditability today? LangChain via LangSmith covers the most at 6 of 12; CrewAI is the only one with a genuine pre-execution record and a first-class agent_id. Neither is audit-ready as shipped. If auditability is a hard requirement, you write the evidence layer yourself and treat the framework's trace as an input to it.

Is a hash chain overkill for an internal tool? Usually, yes. The test is whether anyone outside the team might ever need to rely on the log — a customer, a counterparty, an insurer, an incident review with real consequences. If no, a good trace is enough. If maybe, the chain is far cheaper to add now than to reconstruct later.

We counted fields because the argument about agent oversight has run for months on adjectives, and a field name is either in the class or it is not.

Which single field would you add first to your own agent logs — the pre-execution record, or the hash chain? We would take the pre-execution record, and we would like to be argued out of it.

Written by Decoding AI. We measure things about AI systems that other people describe — token costs, agent traces, protocol diffs — and publish the numbers with the method attached.

AI Agent Audit Logs Need 12 Fields. We Counted 6 Frameworks — the Median Records 5. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.

── more in #ai-safety 4 stories · sorted by recency
── more on @openai-agents-python 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/ai-agent-audit-logs-…] indexed:0 read:7min 2026-09-09 ·