The distinction most agent deployments get wrong
Every production system generates logs. Application logs, access logs, event logs. They accumulate in storage, get indexed by observability platforms, and serve their purpose when an engineer needs to debug a failing service. Logs are essential infrastructure. They are also, categorically, not audit trails.
The difference matters because the question changes when the actor is an AI agent. When a human operator modifies a production database, the organisation can reconstruct the chain of authority through access control records, change management tickets, and the operator's own account of their reasoning. When an agent modifies that same database, the only record of what happened, in what order, and under whose authority is whatever the system captured at the time. If the system captured logs, you have a debugging tool. If the system captured an audit trail, you have evidence.
An audit trail is a contemporaneous, immutable, causally ordered record of actions taken, the authority under which they were taken, and the outcomes they produced. It is created at execution time, as part of the execution, with the same integrity guarantees as the action itself.
A log is a side channel. It records observations about what happened, often after the fact, often with gaps, and almost always without cryptographic proof that the record has not been altered since creation.
Why does the distinction become a compliance requirement?
Regulatory frameworks do not ask whether you can reconstruct what happened. They ask whether you can prove it. SOC 2 Type II, ISO 27001, the EU AI Act's transparency obligations for high-risk systems: each of these requires the organisation to demonstrate that it maintained authoritative records of consequential actions. The word "authoritative" is doing significant work in that sentence. It means the record is contemporaneous, complete, tamper-evident, and attributable to a specific actor under a specific grant of authority.
Post-hoc reconstruction fails every one of those tests. Assembling a timeline from distributed log files after an incident is a forensic exercise, valuable for root cause analysis, insufficient for compliance. The timestamps may not be synchronised. The log entries may have been rotated, truncated, or overwritten. The causal ordering may be ambiguous. And critically, there is no proof that the logs were not modified between the time of the action and the time of the audit.
This is not a theoretical concern. It is the precise scenario that auditors are trained to probe. When an auditor asks "show me the record of this agent's actions on this date," the answer cannot be "give us a few hours to query our log aggregator and correlate the entries." The answer must be a single, retrievable record that stands on its own.
What "system of record" means when the actor is an agent
A system of record is the authoritative source for a specific category of data. In finance, the general ledger is the system of record for transactions. In HR, the HRIS is the system of record for employee data. The defining characteristic is that it is the canonical source from which all other representations derive. When there is a discrepancy between the system of record and any other source, the system of record wins.
When the actor in your production environment is an AI agent, the question becomes: what is the system of record for that agent's actions? Where is the authoritative record of what it did, what inputs it received, what tools it invoked, what outputs it produced, and under whose delegated authority it operated?
For most organisations deploying agents today, the honest answer is that no such system of record exists. The agent's actions are scattered across application logs, LLM provider logs (which the organisation may not even own), tool invocation records in various downstream systems, and perhaps some custom telemetry. No single source is authoritative. No single source is complete. And no single source can prove that its records have not been altered.
This is the compliance gap. Organisations have observability for their agents in the same way they have observability for any distributed system. They do not have a system of record for agent actions.
The anatomy of an authoritative record
An audit trail entry for an agent action needs to capture several things simultaneously. The identity of the agent. The identity of the human or system that delegated authority to the agent. The scope of that delegated authority, including any constraints or boundaries. The specific action taken. The inputs to that action. The outputs produced. The timestamp, with sufficient precision and synchronisation guarantees. A cryptographic commitment that binds all of these elements together and makes the record tamper-evident.
Each of these elements must be recorded at execution time, as part of the execution pipeline, with the same transactional guarantees as the action itself. If the audit record is written asynchronously, after the action completes, there is a window in which the action exists without a record. If the system fails during that window, the action happened but the record did not.
The record must also be causally ordered. When agent A's output becomes agent B's input, the audit trail must capture that causal relationship explicitly. Timestamp ordering is insufficient because clocks drift, batches get reordered, and distributed systems do not guarantee that wall-clock time reflects causal sequence.
How the record is created at execution time
Covia's approach treats the audit trail as a first-class product of execution. When an agent executes an action through the Grid, the audit record is created as part of the same atomic operation as the action itself. The record includes the agent's identity, the delegation chain that authorised the action, the scoped permissions under which it operated, the inputs and outputs, and a cryptographic commitment to the complete record.
The causal ordering is maintained through the lattice data structure that underlies the Grid. Each action references its causal predecessors explicitly, creating a directed acyclic graph of agent actions that can be traversed in causal order regardless of when the actions were recorded or on which node they executed.
The compliance gap is a design gap
The reason most agent deployments have logs rather than audit trails is that the platforms on which they are built were not designed with audit trails as a requirement. LLM providers give you token-level logs for debugging and billing. Tool invocation frameworks give you execution traces for observability. Application platforms give you request logs for monitoring. Each of these serves its purpose. None of them, individually or combined, constitute a system of record for agent actions.
Closing the gap requires treating the audit trail as a design-time decision. The system must be built so that the record is an inherent product of execution, so that it cannot be bypassed, and so that it provides the cryptographic integrity guarantees that make the record admissible as evidence.
Organisations deploying agents into enterprise environments will eventually face a simple question from their auditor, their regulator, or their board: can you prove what your agents did? The organisations that designed for audit trails will retrieve a record. The organisations that designed for observability will begin a forensic reconstruction.
The agents are already modifying production systems. The question of whether the record is authoritative enough is one that gets answered retroactively, usually at the worst possible time.