← Back to concept explainers

Concept Fable

Audit logs

Conclusion first:An audit log is a system log that records who performed what operations on which resources and when, usually including the operator, identity, timestamp, resource, action, input, output, permission context, request ID and result status. In enterprise Agent deployment, audit logs must cover model calls, tool calls, data reads, approvals, permission changes, failed retries and writes to external systems. Its value is not only post-hoc accountability, but also the foundational evidence for incident replay, compliance proof, customer dispute handling, permission review and control testing.

Audit Log · Security / compliance

Read the story first. There is no rush to give a definition here; let the question grow on its own first.

Fable

The night market accountant's black wooden box remembered every time the door was opened

The seaside night market first had only three rows of stalls. Vendors collected money, made change and closed up relying entirely on their own ledgers. Goods were few and people were familiar, so even if a few copper coins went missing, it could be explained from memory.

Later, the night market connected to orders from distant merchant ships. One stall could collect payment for another stall, warehouses would restock in the middle of the night, and street patrollers could temporarily change prices. The ledgers remained, but each told only the small segment it had seen.

The bookkeeper first asked everyone to write one extra page of summary at the end of each day. The summaries were written carefully, but only conclusions remained: who collected how much today, who replenished how much, who closed which door.

Once some valuable spices went missing. The stall owner said the warehouse never sent them, the warehouse said the street patroller changed the order, and the patroller said the system applied a discount on its own. Everyone had a page of summary, but no one could prove who touched which lock at that moment.

So the accountant fitted every door, every cash box and every price-change sign with a black wooden box. Who opened it, when, with which key, what was changed, and what it looked like before and after—the black box carved it all down in order, impossible to erase, only to append.

A few days later, someone again questioned that a box of goods was missing. The accountant did not start by arguing with anyone, but replayed the records along the black wooden box: the shipping order entered, warehouse acceptance, street patrol price change, stall owner confirmation, and nighttime outbound delivery—each step had a name and time.

The result proved that the goods had not been stolen, but that a price change had triggered an incorrect gift rule. What really needed fixing was not the vendor's honesty, but the automatic outbound conditions after the rule change.

From then on, the night market no longer treated records as a stick for punishing people after the fact. Records were first the system's memory, then the boundary of responsibility; without this layer of memory, any clever automated stall would be just a black box no one could explain. Later, an even thornier job came along. On the surface it looked like just an amplified version of the old problem, but in reality it forced out all the gaps hidden in the process: who takes over first, who can make changes, how to return to the previous step when something goes wrong—places that used to be glossed over by acquaintances' tacit understanding now all had to be spelled out. The person in charge did not urge everyone to be more careful; instead, he walked the site again from start to finish. He had people record every handoff, every failure, and every remedy—which places were merely slow, which places could harm the results, and which places, once wrong, would be hard to trace back.

Reveal

This story is about: audit logs

An audit log is a system log that records who performed what operations on which resources and when, usually including the operator, identity, timestamp, resource, action, input, output, permission context, request ID and result status. In enterprise Agent deployment, audit logs must cover model calls, tool calls, data reads, approvals, permission changes, failed retries and writes to external systems. Its value is not only post-hoc accountability, but also the foundational evidence for incident replay, compliance proof, customer dispute handling, permission review and control testing.

What matters is that it is not just a term, but a structural problem that repeatedly appears in real AI / Agent systems. Understanding it lets you judge when to add a model, when to change a process, and when to add governance.

Metaphor mapping

  • Night market stalls: agents, tools, and business systems running in a scattered way across the enterprise
  • Separate ledgers: ordinary business records that only record local state
  • Daily summary: overly coarse, too late, non-replayable aggregated logs
  • Spice loss: disputes, incidents, or compliance issues triggered by agent actions
  • The black wooden box: audit logs that cannot be tampered with at will
  • Open, price change and outbound records: operator, time, resource, action, input/output and result
  • Replay along records: incident investigation, compliance review, and root cause analysis

Andy Ren Xu's judgment

The practical value of this concept is that it helps you break "AI features that look smart" into deliverable, verifiable, and governable units of work.

Traceobservabilitycompliancepermissionsgovernanceincident response

Related distinctions

This concept is easily confused with adjacent concepts; it is recommended to continue to the comparison page.

京ICP备2026014272号