A Reference Architecture for Multi-Agent Audit Trails

The audit trail for a multi-agent system is not a log. It is a reconstructable record of how a specific outcome happened, with sufficient detail that an internal auditor, an external regulator, or an incident reviewer can answer the question what did the system do, in what order, on what basis, with what authority. Most systems shipped to production in 2026 produce a log that the engineering team can read; few produce an audit trail that an auditor can use without translation.

This article describes a reference architecture for multi-agent audit trails that we have deployed in HIPAA-covered healthcare, SR 11-7-scoped financial services, and FedRAMP-scoped government workflows. The architecture is opinionated. It assumes that audit-trail completeness is a first-class design requirement, not a logging concern.

What an Audit Trail Must Reconstruct

An audit trail must let a reviewer answer six questions about any specific workflow outcome. What goal triggered the workflow? What policy was in force at the moment the workflow began? What plan did the agent produce? What tools did the agent invoke, in what order, with what inputs and outputs? What state did the agent observe at each step? What supervisor interventions occurred, and on what basis?

Each of these questions corresponds to a distinct evidence artifact that the architecture must produce. None of them is satisfied by a chat log of model reasoning. The reasoning the model verbalizes is often a post hoc rationalization of a decision driven by other factors; an audit trail that relies on it as the basis of explanation will produce explanations the auditor cannot defend.

The Six Evidence Streams

The reference architecture produces six evidence streams during every workflow run. The Goal Stream records the goal that triggered the workflow, its source (user, scheduled job, upstream system), the authentication context, and the policy contract version selected. The Plan Stream records every plan emitted by the planner, with the prompt and model version used to produce it, and the supervisor's evaluation of the plan against policy.

The Tool Stream records every tool invocation: the tool name, the arguments, the response, the latency, and the data classifications crossed. The State Stream records every checkpoint of agent state, with sensitivity classification of the contents and access logs. The Supervisor Stream records every intervention the supervisor made (plan blocked, tool call rejected, threshold breach detected) with the policy basis for the intervention. The Outcome Stream records the final outcome of the workflow with provenance back to the contributing decisions.

Cryptographic Timestamping

The order of events in an audit trail must be defensible. A trail that orders events by wall-clock timestamps recorded by individual services is vulnerable to clock skew and to malicious or accidental backdating. The reference architecture uses a cryptographic hash chain: each event in a workflow stream is hashed with the hash of the previous event, producing a tamper-evident sequence. The chain head for each workflow is periodically anchored to an external timestamping service.

This is not theoretical hardening. In regulated incident reviews, the question of when events occurred and in what order is litigated. A timestamp chain that an auditor can independently verify is dispositive. A log file ordered by wall-clock timestamps is not.

Separation of Operational and Audit Logging

Operational logging and audit logging have different retention, indexing, and access requirements. Operational logs are queried by engineers, retained for weeks to months, and indexed for search performance. Audit logs are queried by auditors and regulators, retained for years (HIPAA requires six years, SEC 17a-4 requires seven), and indexed for retrieval by workflow identifier.

The reference architecture separates them. Operational logs go to an observability platform; audit logs go to a write-once compliance archive with cryptographic integrity. Engineers cannot modify audit logs. Audit log access is itself logged. The separation is not for elegance; it is because retention, integrity, and access controls have different requirements that cannot all be satisfied by a single store.

Workflow-Level Correlation

Every event in every stream carries a workflow identifier and a step identifier within the workflow. Cross-stream queries reconstruct a complete workflow by joining streams on the workflow identifier. The workflow identifier is propagated through every tool call and agent message, so a tool call made by a sub-agent on behalf of an orchestrator carries the original workflow identifier and not a new identifier scoped to the sub-agent.

This propagation is the architectural commitment that makes cross-agent audit trails possible. Without it, reconstructing a multi-agent workflow from the constituent agents' logs requires inferring relationships from timing and content. Inferred relationships are challengeable in an incident review. Propagated identifiers are not.

Policy Version Binding

The policy that governed an agent's behavior at the moment of a decision must be recoverable from the audit trail. The reference architecture stores the policy as versioned code, and every workflow records the specific commit of the policy in force at workflow start. If the policy changes during a long-running workflow, the change is itself a recorded event with the new commit and the rationale.

A regulator asking what policy was the system operating under when this decision was made will receive a specific commit hash. The auditor can read the policy code and evaluate whether the decision was consistent with the policy. This is the operational definition of policy-as-code: a code artifact, version-controlled, deployed alongside the system, referenced by audit events.

The Audit Packet

Auditors and regulators do not query log streams. They consume audit packets. The reference architecture provides a generation function that, given a workflow identifier, produces a complete packet containing the goal, the policy, the plan history, the tool trace, the state checkpoints, the supervisor interventions, the outcome, and the cryptographic chain proof. The packet is self-contained: an auditor with no access to the production system can validate it.

Packets are generated continuously into the compliance archive. On demand, an auditor can request the packet for a specific workflow or for all workflows matching a query (all workflows that resulted in a denial, all workflows touching a specific patient, all workflows that fired a kill switch). Generation is fast because the underlying streams are indexed for this access pattern.

Continuous Assurance Reports

Beyond per-workflow audit packets, the reference architecture produces continuous assurance reports that aggregate workflow-level data into the metrics regulators and internal audit teams consume. Examples: the rate of supervisor interventions per thousand workflows, the rate of plan-block events by policy rule, the distribution of plan lengths, the rate of hallucinated tool calls, the rate of human-in-the-loop escalations. Quarterly trend reports surface drift in these metrics that warrants investigation.

The assurance reports are themselves generated from the audit log, not from a parallel operational data source. This is intentional: there is one source of truth for what the system did, and both forensic investigation and continuous monitoring read from it.

What Most Systems Miss

Three architectural commitments differentiate audit-grade trails from logs. The first is the separation of operational and audit logging with different retention and integrity properties. The second is workflow-level correlation propagated through agent boundaries. The third is the audit packet as the consumption interface for auditors. Systems that miss any of these have logs that engineers can read; they do not have audit trails that regulators will accept without months of forensic work.

The right time to build these commitments is at architecture time. The wrong time is after the first regulatory inquiry, when the inquiry itself is the deadline for producing evidence the system was not designed to produce.