How to Audit What an AI Agent Actually Did

The Audit Log is found at Admin → Settings → Audit Log tab. It records every significant action in the platform as an immutable audit event. For AI agent operations, that means workflow creation and modification, workflow execution starts and completions, agent configuration changes (including every version creation and retirement), and authentication events for every user who interacted with the system during a workflow run.

Each audit event captures eight fields:

• Timestamp: when the event occurred, to the second.
• Event Type: a categorized label for the action, such as workflows.create, workflows.update, or auth.login.
• Actor: the user who performed the action, identified by email address and user ID.
• Entity: the object affected, identified by type (for example: workflow, agent, secret) and ID.
• HTTP Context: the request method, path, and status code.
• IP Address: the source IP of the request.
• User Agent: the browser or client that made the request.
• Details: the sanitized request body, with passwords, secrets, and tokens automatically redacted and large payloads truncated.

The log is sorted most-recent-first by default. Click any row to expand it and see the full event details as formatted JSON, including the complete actor information, entity type and ID, and all captured metadata.

Events are color-coded for quick visual scanning: green for create and start events, blue for updates, red for deletes and failed logins, purple for login events, amber for compliance changes and cancellations, and cyan for completions. When you are looking for the moment a workflow started or an agent configuration changed, the color coding lets you scan the table quickly without reading every row.

A busy workspace accumulates audit events quickly. Four filtering controls let you narrow the log to exactly the events you need.

Text search

The text search field searches across actions, email addresses, paths, and entity IDs simultaneously. To find all events related to a specific agent, search for the agent's ID. To find all actions performed by a specific user, type their email address. To find all events on a specific workflow execution, search for the workflow ID or instance ID. The search is live: the table updates as you type.

Event Type filter

The Event Type dropdown lists every distinct event type present in your log. Use it to filter to a specific category of action. For agent-related investigations, the event types you are most likely to need are workflow execution events (which capture the start and completion of workflow instances that invoke agents) and agent configuration events (which capture version creation and retirement).

Entity Type filter

The Entity Type dropdown lists every distinct entity type in your log. Filter by workflow to see all workflow-level events, or by agent to see all agent configuration changes. Combining an Entity Type filter with a text search for a specific ID is the fastest way to reconstruct the full history of a single object.

Date range filter

Use the From and To date pickers to scope the log to a specific time window. For incident investigations, set the range to the period when the unexpected behavior occurred. For compliance evidence, set the range to the audit period your auditor has requested. Click Clear filters to reset all filters back to their defaults.

You can also sort the table by clicking any column header: Time, Event Type, Actor, Entity Type, Method, Status, or Action. Sorting by Actor is useful when you want to see all actions by a specific user in chronological order. Sorting by Status is useful when you want to surface failed requests quickly.

When something unexpected happens in an AI workflow, the audit event for that action tells you four things: who authorized it, what system action it produced, when it happened, and from where. Here is how to read an expanded event row for each of those questions.

Who authorized it

The Actor field shows the email address and user ID of the person whose credentials were used to perform the action. In a workflow context, the actor for a workflow execution start is the user who triggered the run. The actor for an agent version creation is the user who made the configuration change. If a workflow was triggered by an automated process using an API client, the actor will reflect the API client's identity rather than a human user.

What system action it produced

The Event Type and Details fields together describe what happened. The event type gives the category; the details JSON gives the specifics: the entity IDs involved, the request body (sanitized), and any metadata captured at the time. For agent configuration changes, the details will include the Config JSON that was submitted, giving you a precise record of what instruction set was active at any point in the workflow's history.

When it happened

The Timestamp field records the exact moment of the event. Cross-referencing timestamps across multiple events lets you reconstruct a precise timeline: when the workflow started, when each agent node executed, when the configuration was last changed before the run, and when the run completed or failed.

From where

The IP Address and User Agent fields record the source of the request. These are useful for security investigations: if an action was performed from an unexpected IP address or an unfamiliar client, that is a signal worth investigating. The HTTP Context field (method, path, status code) confirms which API endpoint was called and whether the request succeeded.

For a complete picture of a workflow run, combine the audit log with the workflow instance detail page, which shows the execution state of each node. The audit log tells you who did what at the system level; the instance detail tells you what the workflow produced at the application level.

By default, the Audit Log captures mutating requests: actions that create, update, or delete something. When SOC 2 or GDPR compliance standards are enabled (in Admin → Settings → General → System Parameters → Audit Log), the log extends to also capture read access to sensitive endpoints.

With a compliance standard enabled, GET requests to the following endpoints are logged in addition to mutations:

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

These read-access events include a complianceTriggered: true flag in their details, distinguishing them from standard mutation events. For AI agent workflows that access secrets (such as API credentials stored in the per-tenant vault), this means you have a record not just of when a secret was created or changed, but of when it was accessed and by which workflow context.

Compliance events are marked with colored badges next to their event type: a blue SOC2 badge for events tagged to SOC 2 compliance, and a purple GDPR badge for events tagged to GDPR compliance. An event may carry both badges. The compliance tags are stored in the event's complianceTags array within the details payload, making them available in CSV exports for auditor submission.

When an admin enables or disables a compliance standard, the system automatically creates an audit.compliance_changed event recording the before state, the after state, and exactly what was added or removed. This gives you an immutable record of when compliance requirements were modified and by whom, which is itself a compliance requirement under several frameworks.

DAVE's credential vault uses AES-256-GCM authenticated encryption. Credentials stored in the vault are never returned through the API once stored. The audit log records access events for the vault endpoints when compliance mode is active, giving you a complete picture of credential access without exposing the credential values themselves.

The Audit Log supports two export methods. For a single event, click the copy icon on the row to copy that event's full details to your clipboard as JSON. For a set of events, click the download button to export all currently filtered results as a CSV file. The CSV includes all event fields and is suitable for compliance record-keeping and external audit submissions.

A practical note on CSV export: the export includes only events that match your current filters. If you want a complete export for a time period, use the date range filter to scope the window and clear all other filters before downloading. If filters are active when you export, events outside those filters will not appear in the CSV. The Troubleshooting section of the Audit Log help page calls this out explicitly: click Clear filters first if you are not sure whether filters are active.

Retention is configured in Admin → Settings → General → System Parameters → Retention Policy. The default retention period is 365 days. For SOC 2 compliance, the recommended minimum is 2,555 days (7 years): DAVE displays a warning if your retention is set below this threshold when SOC 2 is enabled. Setting retention to 0 retains audit logs indefinitely.

For AI governance programs, the retention setting is a policy decision, not just a technical one. The audit log is the primary evidence that your AI agents operated within their defined parameters, that configuration changes were authorized, and that human review steps were completed where required. If your retention period is shorter than your governance or legal requirements, export audit logs as CSV before they are automatically purged by the scheduled cleanup task.

Only users with the Admin role (specifically admin:* or audit:read permissions) can view, filter, export, or copy audit log data. DAVE ships with six default tenant roles (Admin, Create, Curate, Use, Reporting, and Financial), all editable by your administrator. No other default role has access to the Audit Log tab.

Human-in-the-loop design is not just about inserting Human Review nodes into workflows. It is about being able to demonstrate, after the fact, that the humans in the loop actually reviewed what they were supposed to review, that the AI agents operated within their configured parameters, and that any configuration changes were authorized by the right people at the right time.

The Audit Log is what makes that demonstration possible. Without it, human-in-the-loop is a design intention. With it, it is an auditable fact.

For teams building AI workflows in regulated industries or under internal governance requirements, the practical implication is this: design your audit strategy alongside your workflow design, not after it. Decide which event types matter for your governance requirements before you build. Enable the compliance standards that match your framework. Set retention to cover your audit window. And use the date range filter and CSV export regularly, not just when something goes wrong.

The Audit Log answers the question "what did that agent actually do?" But it also answers the harder questions: who authorized the configuration it was running under, who reviewed its output before it was acted on, and when did all of that happen. Those answers are what turn an AI workflow from a black box into an accountable system.