How to Keep an AI Agent Accountable in a Business Process

An agent cannot be accountable if its configuration changes without a record. The first mechanism DAVE provides is versioned, immutable agent configurations.

Every agent in DAVE maintains an independent version history. Each version is a numbered, immutable snapshot of the agent's Config JSON: the system prompt, model, temperature, and any other behavior parameters. Version numbers are auto-incremented integers (v1, v2, v3) assigned by the system. You cannot edit a version after it is created, and you cannot skip or reuse version numbers. If you need to change an agent's behavior, you create a new version. The old version remains in the history, unchanged.

This matters for accountability because it means you can always answer the question: what configuration was running when this output was produced? Every workflow instance that reaches an Agent Interaction node records which agent version it used. If an agent produces unexpected output, you can open the agent detail page (navigate to Agents in the sidebar, then click the agent name), find the version that was active at the time, and read the exact Config JSON that drove the behavior.

Retiring versions as a control mechanism

When a version is superseded by a newer one, retire it. Retiring marks the version with a retiredAt timestamp and displays an amber Retired badge on the version row. A retired version cannot be selected for new workflow assignments. Existing running instances that already reference it are not affected: they continue to use the configuration until they complete. But no new instance can be pointed at a retired version, which means you control exactly which configurations are available for future use.

Retiring is a one-way action. You cannot un-retire a version. If you need the same configuration again, create a new version with the same JSON. This one-way constraint is a feature: it prevents silent rollbacks and keeps the version history honest.

The practical discipline is: create a new version, test it, confirm it works, then retire the old one. Never leave multiple active versions of an agent in production unless you have a deliberate reason for each one to be available.

Who can change agent configuration

Only users with the Admin or Create role can create agents, create versions, or retire versions. The Curate role can view agents and reference them in the Workflow Editor but cannot modify them. The Use and Reporting roles cannot access the Agents section at all. DAVE ships with six default tenant roles (Admin, Create, Curate, Use, Reporting, and Financial), all editable, so your administrator can align access to your governance requirements.

This role separation means that the people who run workflows (Use role) cannot change the agent configurations those workflows depend on. Configuration changes require a deliberate act by someone with the Create or Admin role, and every such change is logged.

The second accountability mechanism is the audit log. Every significant action in DAVE, including all agent operations, is automatically recorded as an immutable audit event. The log is found at Admin → Settings → Audit Log tab and is accessible only to users with the Admin role (specifically admin:* or audit:read permissions).

Each audit event captures a consistent set of fields:

• Timestamp: when the event occurred.
• Event Type: a categorized label for the action (for example, auth.login, users.create, tenant.update).
• Actor: who performed the action, identified by email address and user ID.
• Entity: what was affected, identified by entity type and ID.
• HTTP Context: the request method, path, and status code.
• IP Address: the source IP of the request.
• Details: the request body, sanitized so that passwords, secrets, and tokens are automatically redacted.

Click any row in the audit log table to expand it and see the full event details, including formatted JSON with all captured metadata.

What agent-specific events look like in the log

Agent operations that appear in the audit log include: creating an agent, updating an agent, creating a new version, and retiring a version. These events are tracked as configuration changes. When SOC 2 compliance is enabled for the tenant, agent version changes are tagged for SOC 2 CC8.1 (change management), making them part of the formal compliance evidence record.

Prompt injection detection events, when triggered during agent execution, are logged as security events tagged for SOC 2 CC7.2 (anomaly monitoring). AI guidelines injection provides an audit trail of what safety constraints were applied to each agent execution.

Filtering and searching the log

The audit log provides text search (across actions, emails, paths, and entity IDs), an Event Type dropdown, an Entity Type dropdown, and a date range filter. To investigate a specific agent: filter by entity type to scope the results, or enter the agent's ID or name in the text search. To investigate a specific user's actions: enter their email address in the text search to find all events they performed.

The log can be exported as a CSV file using the download button, which exports all currently filtered results. For compliance submissions, use the date range filter to scope events to the audit period before exporting.

Retention: how long the record is kept

Audit log retention is configured in System Parameters → Retention Policy. The default retention is 365 days. For SOC 2 compliance, the recommended minimum is 2,555 days (7 years): a warning is displayed in the settings if retention is set below this threshold. Setting retention to 0 retains logs indefinitely. Cleanup runs automatically via a scheduled background task: once the retention period expires for an event, it is permanently removed during the next cleanup cycle. Export logs before they are purged if your archival requirements exceed your configured retention period.

A versioned configuration and an audit log tell you what happened. A human review gate ensures that a person is accountable for what happens next. This is the third mechanism: placing Human Review nodes in the workflow at points where a human must evaluate agent output before it is used.

When a workflow reaches a Human Review node, execution pauses and a task is generated for the assigned reviewer. The reviewer sees the agent's output in the task payload, makes a decision (approve, reject, or request changes), and optionally adds a comment. The workflow resumes only after the decision is submitted. The decision, the reviewer's identity, and the timestamp are all recorded.

This creates a chain of accountability: the agent produced output under a specific versioned configuration (recorded), a named person reviewed that output and made a specific decision (recorded), and the workflow continued on the path that decision dictated (recorded). Every link in the chain is traceable.

Agent Review as a pre-filter

In high-volume workflows, routing every item through a Human Review node is impractical. The Agent Review node provides an automated pre-filter: an AI agent evaluates output against defined criteria and returns a pass or fail verdict. Items that pass route forward automatically. Items that fail route to a Human Review node for human assessment.

This pattern keeps humans accountable for the edge cases and exceptions, where their judgment adds the most value, without requiring them to review every item mechanically. The Agent Review node's verdict is part of the workflow context and is included in the Human Review task payload, so the human reviewer understands why the item was escalated.

Locked prompts: preventing silent configuration drift

One subtle accountability risk is prompt drift: a workflow designer overrides an agent's system prompt at the node level, changing the agent's behavior without creating a new version and without a clear record. DAVE addresses this with prompt locking.

When a library prompt is assigned to an agent and the Lock Prompt toggle is enabled, the prompt selector for that agent is greyed out in the Workflow Editor. Workflow designers cannot override it. The agent always uses its locked prompt, regardless of which workflow references it. This ensures that every workflow using the agent applies the same, reviewed, version-controlled prompt, and that any change to the prompt requires a deliberate act by someone with the Admin or Create role, which is then logged.

The fourth mechanism is compliance mode. When SOC 2 or GDPR compliance is enabled for a tenant, DAVE extends its logging and tagging to produce structured evidence that maps directly to compliance control requirements.

Compliance modes are enabled in Admin → Settings → General → System Parameters → Audit Log. When enabled, events display colored compliance badges next to their event type in the audit log table: a blue SOC2 badge and a purple GDPR badge. Compliance tags are stored in the event's complianceTags array within the details payload, making them queryable and exportable.

What compliance mode adds for agent accountability

• Read-access logging. Without compliance mode, only mutating requests (create, update, delete) are logged. With SOC 2 or GDPR enabled, GET requests to sensitive endpoints are also logged, including reads of agent configurations and secrets. These events include a complianceTriggered: true flag in their details.
• Agent version changes tagged CC8.1. Every agent version creation and retirement is tagged for SOC 2 CC8.1 (change management), providing auditors with a structured record of configuration changes to AI components.
• Prompt injection events tagged CC7.2. When prompt injection detection is enabled and a pattern is detected, the event is tagged for SOC 2 CC7.2 (anomaly monitoring), contributing to the security monitoring evidence record.
• Compliance change events. 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 what specifically changed. This provides an immutable record of exactly when compliance requirements were modified and by whom.

Retention for compliance

SOC 2 recommends at least 7 years of audit log retention (2,555 days). If SOC 2 is enabled and your retention setting is below this threshold, a warning is displayed in the settings. Review your retention configuration when enabling compliance mode and address any warnings before your next audit period.

These are the checks to run before any agent-driven workflow goes into production. Each item maps to a specific mechanism in DAVE.

Configuration

• Every agent has at least one non-retired version. An agent with no active versions cannot execute. An agent with multiple active versions may behave inconsistently across workflows. Confirm that each production agent has exactly one active version and that all superseded versions are retired.
• Config JSON is documented. The system prompt and model choice in the Config JSON should be self-explanatory to anyone reading them. If they are not, add a description to the agent's Description field explaining what the agent does, what inputs it expects, and what output it produces. The description is visible on the agent detail page.
• Prompts are locked where consistency is required. For any agent used in a compliance-sensitive or safety-critical workflow, enable Lock Prompt so the system prompt cannot be overridden at the workflow node level.

Workflow structure

• Every agent output has a downstream review step. Confirm that every Agent Interaction node in a production workflow is followed by either an Agent Review node (automated check), a Human Review node (human judgment), or both. An agent whose output flows directly to an API Call node or an End node with no review step is an unaccountable agent.
• Human Review nodes have complete payloads. The payload passed to a Human Review task should include the agent's output, the original input or brief, and any automated review findings. A reviewer who sees only the output cannot evaluate whether it is a correct response to the input.
• Revision loops have exit conditions. Any workflow branch that routes back to an Agent Interaction node for revision must have a maximum iteration count enforced by a Routing node. A loop with no exit is an accountability gap: the workflow can cycle indefinitely with no human ever making a final decision.

Audit and compliance

• Audit log access is assigned to the right people. Only users with the Admin role can view the audit log. Confirm that the people responsible for security investigation and compliance evidence have Admin role access, and that this access is not granted more broadly than necessary.
• Retention is set for your compliance requirements. Check the retention setting in System Parameters → Retention Policy. If SOC 2 is enabled, confirm retention is at least 2,555 days or address the warning shown in settings.
• Compliance mode is enabled if required. If your organisation operates under SOC 2 or GDPR requirements, confirm that the relevant compliance standard is enabled in Admin → Settings → General → System Parameters → Audit Log. Without it, read-access events are not logged and compliance badges do not appear on events.