What Belongs in an AI Audit Trail: A Practical Field Guide

An audit event is only as useful as the information it captures. An event that records what happened but not who did it, or when, or from where, cannot support a security investigation or satisfy a compliance auditor. The minimum viable AI audit event needs eight fields, each answering a specific question an investigator will ask.

DAVE captures all eight on every recorded event:

1. Timestamp. When did this happen? Recorded to the second. Without a precise timestamp, you cannot reconstruct a sequence of events, establish causation, or determine whether an action fell within a compliance observation period. Timestamps should be immutable: a log where timestamps can be edited after the fact is not an audit log.

2. Event Type. What category of action was this? A structured, categorised label such as auth.login, users.create, tenant.update, or audit.compliance_changed makes the log filterable and machine-readable. Free-text descriptions are not sufficient: you cannot reliably filter or export by event type if the type field is unstructured.

3. Actor. Who performed the action? Captured as both the email address and the user ID of the person who made the request. Email alone is insufficient because email addresses can be reassigned; user ID alone is insufficient because it is not human-readable. Both together give you an unambiguous, human-readable, and programmatically stable identifier for the person responsible.

4. Entity. What was affected? The type of object (for example: user, workflow, secret, role) and its ID. Without the entity, you know that something happened but not what. With the entity type and ID, you can reconstruct the full history of any object in the system by filtering the audit log to that entity.

5. HTTP Context. How was the action performed? The request method (POST, PUT, PATCH, DELETE, GET), the path, and the HTTP status code. This field distinguishes a successful action from a failed attempt, and it identifies the specific API endpoint that was called. For AI workflow platforms with large API surfaces, the path is often the most precise indicator of what the actor was trying to do.

6. IP Address. Where did the request originate? The source IP of the request. This field supports geolocation analysis during incident investigation, helps identify requests from unexpected locations, and is required by several compliance frameworks as part of access records.

7. User Agent. What client made the request? The browser or API client that sent the request. This field helps distinguish human-initiated actions (browser user agents) from automated or programmatic actions (API client user agents), which is relevant when investigating whether an action was taken deliberately by a person or by an automated process.

8. Details. What was the content of the action? The request body, sanitized. This is where the specifics live: what fields were changed, what values were set, what configuration was modified. Sanitized means that known sensitive values, specifically passwords, secrets, and tokens, are automatically redacted before the event is written to the log. Large payloads are truncated. The sanitization happens at capture time, not at display time: the plaintext value is never written to log storage.

These eight fields are the foundation. An AI audit log that captures fewer than all eight is missing information that will matter at the worst possible moment.

Most audit logs record mutations: create, update, and delete operations. This is a reasonable baseline. If someone deletes a user account, modifies a workflow, or changes a role configuration, you want a record of it. But for AI workflow platforms, mutations-only logging leaves a significant gap.

Consider the scenarios that mutations-only logging cannot answer:

• An admin views the full list of users and their email addresses. No record.
• A user with elevated permissions reads the secrets vault configuration. No record.
• Someone pulls a report containing sensitive operational data. No record.
• An API client reads the OAuth provider configuration. No record.

In each case, no data was changed, so no mutation event was generated. But data was accessed, and in a GDPR or SOC 2 context, access to personal or sensitive data is exactly what needs to be recorded.

DAVE addresses this through read-access logging, which is activated when SOC 2 or GDPR compliance standards are enabled. With either standard active, GET requests to the following sensitive endpoint categories are captured in the audit log alongside mutation events:

• Users
• Roles
• Secrets
• API Clients
• OAuth Providers
• Reports

Each read-access event carries the same eight fields as a mutation event, plus a complianceTriggered: true flag in its details that distinguishes it from a standard mutation event. This flag makes it straightforward to filter the audit log to compliance-triggered read events specifically, which is useful when preparing evidence for a subject access request under GDPR Article 15 or an access control review under SOC 2 CC6.

Without compliance standards enabled, only mutating requests (POST, PUT, PATCH, DELETE) are logged. The decision to activate read-access logging is explicit and recorded: enabling a compliance standard generates an audit.compliance_changed event that captures the before state, the after state, and exactly what was added. An auditor can verify not just that read-access logging was active during a given period, but precisely when it was turned on and by whom.

A complete audit trail for an AI workflow platform covers a wide surface area: authentication, user management, role and permission changes, workflow lifecycle events, provider configuration, compliance standard changes, and more. Without structure, a log of this breadth becomes difficult to navigate during an incident when speed matters.

Two structural features make a large audit log usable: categorised event types and visual differentiation by event category.

Categorised event types give every event a machine-readable label that can be filtered, exported, and searched programmatically. In DAVE, event types follow a dot-notation convention: the prefix identifies the domain (auth, users, tenant, audit, workflows) and the suffix identifies the action (login, create, update, delete, compliance_changed). This convention makes it possible to filter to all authentication events, all user creation events, or all compliance configuration changes with a single filter selection, rather than searching free text.

Visual color coding by event category supports rapid human scanning of the log. DAVE uses six colors:

• Green: create, activate, and start events. Something new was created or a process was initiated.
• Blue: update events. An existing record was modified.
• Red: delete events and failed login attempts. Something was removed or an authentication attempt failed.
• Purple: successful login events. A user authenticated.
• Amber: compliance changed and cancelled events. A compliance standard was modified or an operation was cancelled.
• Cyan: completed events. A process reached its end state.

The practical value of color coding is speed during investigation. When reviewing a timeline of events around a suspected incident, the ability to visually distinguish a deletion (red) from an update (blue) from a login (purple) without reading each event type label reduces cognitive load and accelerates the investigation. This is not an aesthetic choice: it is a usability decision with direct operational consequences.

The combination of structured event types and visual differentiation means an investigator can arrive at the audit log, apply a date range filter, scan for red events (deletions and failed logins), and expand the relevant rows for full details, all within a single interface without exporting to a separate tool.

The details field of an audit event is where the specifics of an action live. It is also the field most likely to contain sensitive values if it is not handled carefully. A log that captures raw request bodies including API keys, passwords, or tokens satisfies the letter of audit logging requirements while creating a new attack surface: the log itself becomes a credential store.

The correct approach is automatic sanitization at capture time, not at display time. The distinction matters. Sanitization at display time means the sensitive value is written to log storage in plaintext and only masked when rendered in the UI: it is still recoverable from a database backup, a log export, or a direct database query. Sanitization at capture time means the sensitive value is redacted before it reaches storage: it is never written in plaintext form at any layer.

DAVE sanitizes the details field at capture time. Known sensitive fields, specifically passwords, secrets, and tokens, are automatically redacted before the event is written to the audit log. Large payloads are truncated to keep event storage manageable. The result is a details field that is useful for investigators (it shows what configuration was changed, what fields were set, what values were modified) without being a credential recovery mechanism.

There is an important boundary to understand: the sanitization covers known sensitive field names. Other request body fields are captured as-is. This means the details field may contain business data from the request body, such as workflow names, user display names, or configuration values, that are not themselves credentials but may be sensitive in other ways. Organisations with strict data minimisation requirements should review what their audit events capture and assess whether the details field content is appropriate for their compliance posture.

The sanitization behaviour is also relevant to log export. When an Admin exports the audit log as CSV for submission to an external auditor, the exported file contains the sanitized details: redacted where sensitive fields were present, truncated where payloads were large. The export is safe to share with an auditor without a separate review step to strip credentials.

An audit trail is only useful for as long as its records are retained. A log that captures everything perfectly but purges events after 90 days cannot support a SOC 2 Type II audit with a 12-month observation period, a GDPR breach investigation that requires access history from six months ago, or a legal hold on records from last year. Retention is not a secondary concern: it is a prerequisite for the audit trail being useful when it is actually needed.

The most common operational mistake is connecting an AI workflow platform to production data before configuring retention. Events generated before retention is set to a compliant value are not retroactively extended by a later change: they will be purged according to whatever policy was active when they were created. A team that enables SOC 2 mode on day one but leaves retention at the default will have a gap in their audit evidence at the 12-month mark.

In DAVE, audit log retention is configured in Admin, then Settings, then General, then System Parameters, then Retention Policy. The default retention period is 365 days. For SOC 2, the recommended minimum is at least 2,555 days (seven years): the UI displays a warning if retention is set below this threshold when SOC 2 mode is active. Setting retention to 0 retains audit logs indefinitely (Forever), which is appropriate when compliance or legal requirements demand it, but increases storage over time.

The correct operational sequence is: decide on your compliance standards, set retention to match the longest requirement among those standards, then begin production use. This ensures every event generated in production is captured under the correct retention policy from the start. If you are enabling compliance standards on a tenant that already has production data, export a CSV of existing events immediately, before the retention clock on any of them expires.

One additional retention consideration specific to AI workflow platforms: the audit trail covers not just user management and authentication events but also workflow lifecycle events, agent interactions, and compliance configuration changes. The retention policy applies uniformly to all event types. If your organisation has different retention requirements for different event categories, that differentiation needs to be managed through export and archival rather than through the retention setting itself, which is a single value applied to all events.

Whether you are evaluating DAVE or any other AI workflow platform, these are the specific questions that separate a complete audit trail from a logging facade.

Does it capture all eight fields per event? Timestamp, event type, actor (email and user ID), entity (type and ID), HTTP context (method, path, status), IP address, user agent, and sanitized details. Missing any of these fields means missing information that will matter during an investigation or audit.

Does it log reads as well as mutations? A mutations-only log cannot answer who accessed user data, who read the secrets configuration, or who pulled a sensitive report. Read-access logging on sensitive endpoints is a requirement for GDPR Article 15 and SOC 2 CC6 compliance, not a nice-to-have.

Is sanitization applied at capture time or display time? Capture-time sanitization means sensitive values are never written to storage in plaintext. Display-time sanitization means they are stored in plaintext and only masked in the UI: they remain recoverable from exports and backups. The answer should be capture time.

Is the compliance configuration itself logged? A system that claims compliance logging was active during a given period but cannot show an immutable record of when it was enabled cannot provide the assurance an auditor needs. Look for a specific event type for compliance configuration changes, with before and after state captured.

What is the default retention period, and what is the maximum? A default of 30 or 90 days is a signal that the platform was not designed for compliance use cases. The answer should include a specific recommended minimum for the relevant standard and a mechanism to retain logs indefinitely when required.

Can an Admin export date-scoped, compliance-tagged evidence as a file, without a support ticket? If producing audit evidence for an external auditor requires a professional services engagement or a custom data extract, the platform is not operationally ready for a compliance audit. The export should be available in the product UI, in a standard format, scoped to a date range, and inclusive of compliance tags.

DAVE's audit log is designed to answer all six questions affirmatively. The Audit Log tab at Admin, then Settings, then Audit Log is available to Admin users, filterable by event type, entity type, and date range, exportable as CSV, and backed by configurable retention with a SOC 2 warning threshold. The controls are product features you can verify today, not roadmap commitments.