Glossary
What is audit-of-action?
Audit-of-action is the substrate-produced, attributed, tamper-evident record of what an AI agent did. Access control decides what an agent may do; audit-of-action records what it actually did.
§ 01 Definition
What an agent did, not what it was allowed to do.
Audit-of-action is the substrate-produced, attributed, tamper-evident record of what an AI agent did. Every action is bound to the agent that performed it, the action’s inputs and outcome, and a hash-chained entry that an auditor can verify. The record is a property of the substrate the agent runs on, not an artifact the operator has to build, instrument, or maintain.
Audit-of-action is distinct from access control. Access control decides what an agent is allowed to do before an action; audit-of-action records what the agent actually did after. Both matter. An access control decision is a permission; an audit-of-action entry is evidence. A regulator asking whether an AI agent may have acted on protected data is asking about access control. A regulator asking what your AI agent did during a specific time period is asking about audit-of-action. The category difference is what an agent did versus what an agent was allowed to do.
§ 02 Why it matters
Neither a test nor a gate answers what happened.
A test tells you the model probably will not do the wrong thing. Access control tells you the wrong thing was not permitted. Neither answers what actually happened. When an examiner, an auditor, or an incident responder asks that question, the substrate that produced the record is what they interrogate. If the record was reconstructed after the fact from application logs, it is a reconstruction. If the record was produced at the moment of action, attributed to the agent, and hash-chained against tampering, it is evidence in the language a regulator asks for.
Audit-of-action is what the substrate produces by construction. The record is produced as the action happens; no action passes without becoming part of the record. Access control decides what may happen. The substrate records what did. That property is what differs from log-shipping and from bolt-on instrumentation: at fleet scale, no per-application effort is required to get the record.
§ 03 Questions
Audit-of-action, answered.
How is audit-of-action different from access control?
Access control decides what an agent is allowed to do; audit-of-action records what the agent actually did. Access control produces a permission before the action. Audit-of-action produces evidence after the action. Both are load-bearing. See audit-of-action vs access control for the category-difference framing.
What does the substrate produce that a log-shipping pipeline does not?
Attribution at the moment of action. A log-shipping pipeline stitches events together after the fact and asks the operator to trust that the stitching preserved the truth. The substrate records the action as it happens, binds it to the agent that performed it, and hash-chains the entry so any later alteration is detectable. See what is a tamper-evident audit log for the integrity property.
Which regulatory frames expect audit-of-action?
SR 26-2’s broader-governance posture presupposes an interrogable record for the agentic AI it excluded from model-risk scope. NERC CIP’s CIP-007 R4 security-event-monitoring expectations for AI agents on BES-adjacent systems assume attributable evidence. For high-risk AI systems under Annex III, the EU AI Act Article 12 record-keeping obligation calls for the kind of evidence audit-of-action produces. Colorado SB 26-189 requires developers and deployers of automated decision-making technology to retain records demonstrating compliance for 3+ years.
§ 04 Related
Where the term lives.
Regulatory frames