Audit log evidence: scope, gaps, and verification
This reference lists what the Duale AI audit log records, identifies evidence gaps, and explains how to verify record content.
This page covers what the audit log records, its gaps, Tool Analytics, Task content access, query limits, hash verification, and linking Platform failures to business records.
- Audit log recorded events and their content.
- Evidence gaps absent from the audit log.
- Tool Analytics aggregate outcomes and their limits.
- Task content access and query interface limits.
- Record hash verification and Platform failure correlation.
Summaries were generated by AI.
Use the audit log as supporting evidence for the events below. When a business, audit, contractual, legal, support, or recovery need depends on a missing event, the gap table identifies evidence an existing customer system can keep.
When you must retain an approval, decision, or exception, keep it in its existing change or business record. Platform records can support that record, but they do not contain the customer’s decision.
What Duale AI records
Use the audit log to support these events:
| Recorded | What the record carries |
|---|---|
| Tenant, Agent Identity, member, token, and invitation changes | Who acted, what changed, before and after |
| Configuration changes, including model routes | The change, with secret values redacted |
| Configuration and directory reads | An access event |
| Tenant policy, group, and binding changes | The reported change and the resolved acting identity |
| Platform-supplied policy and role changes | The version, policy-definition and supplied-group changes, and group-level grant diff, with audit-only system provenance |
| Library access-grant changes | The subject, action, and effect of the grant |
| Task lifecycle | Completion, timeout, and stop |
| Tool requests | The name of each Built-in, SDK, or MCP Tool that a Task sent a request to, recorded when Duale AI sends the request |
| Authorization decisions | A sample of decisions: a repeated check within a short time is not recorded again |
| Credential refusals with an identified Tenant | The presented key identifier, refusal reason, and acting identity when resolved |
Use these entries as supporting evidence, then check the next section for the records that do not exist. Default policies explains why a supplied-policy definition diff does not prove that every Tenant member’s effective permissions changed. Credential lifecycle explains how to correlate recorded refusals and where the coverage stops.
An event marked success reports the outcome that the acting component reported. The record alone does not prove that the corresponding
state change committed; if that distinction matters, check the current resource state or the owning change record.
What the audit log does not record
Each row identifies evidence absent from the audit log. Task-view observations and customer records have the separate limits described below.
| Not recorded | What no record can show | Possible customer evidence |
|---|---|---|
| Document lifecycle actions. Uploading or deleting a document in a Library raises no audit event. | Who uploaded or deleted a document | An existing action record, written at that moment, when you need this proof |
| Document reads. A Task reading a document raises no audit event. | Which document a Task read | Not available from current public interfaces |
| Policy-change approval. A record of an applied policy change does not contain your approval decision. | Who approved that change and against what evidence | The existing change record, when approval must be retained |
| Every authorization decision. The record holds a sample of decisions, not every one. | A complete access-decision history | Nothing |
| Credential refusals before Tenant identification. A refused platform token that Duale AI cannot link to a Tenant is not in that Tenant’s log. | Every presentation of an expired or deleted platform token | Failure information returned to your own client |
| Per-call Tool completion and result. The audit request event precedes execution. | A verified external Effect from the request event alone | The Task view shows retained call outcomes and results; verify the destination in its owning system |
| Model selection. The Tool request record names the Tool, not the model choice. | Why a given model ran a Task | Usage analytics show provider and model for recorded work. Nothing records the reason |
| Why two comparable Tasks differ. The audit log does not reconstruct model selection. | Why two otherwise comparable Tasks differ | The Executor shows its accepted routing policy; that policy is not a complete explanation of the model choice |
| Model-pool approval. A configuration change does not contain the customer’s approval evidence. | Who approved the change and against what evidence | The existing change record, when approval must be retained |
| Library-sharing approval. A Grant record describes the applied rule, not the customer’s approval decision. | Who approved the share and for what purpose | The existing change record, when approval must be retained |
| Task Result acceptance. Business acceptance is not a Platform event. | Why your application or reviewer accepted a result | The existing business record, when acceptance evidence is required |
Use Tool Analytics for aggregate outcomes
Tool Analytics in the Dashboard counts one final outcome for each requested Tool Call, not each retry, and aggregates those outcomes across the Tenant and by Tool Source, model-facing Tool name, and Agent Identity. The aggregates can show whether a Connection or Tool fails more often and which Agent Identities use it. They do not expose arguments or results, identify the effect of one call, or prove that the destination system changed.
Operate Tools owns the outcome categories, the confirmed success rate, and when that rate appears. Tool Call outcomes defines what each outcome means.
Read recorded Task content
The Task view shows retained original messages, provider-returned reasoning, Tool inputs and Tool Results, including Library excerpts and Recall results already recorded in that Task. Redacted provider reasoning is excluded. Duale AI’s private system and developer instructions do not appear. Content is not redacted at display time: a secret or personal datum recorded in a message or result can be visible there.
The agent:read_task permission for that Task opens both its recorded content and its recorded work. Grant it
narrowly. There is no additional content permission, and a shared link grants nothing. A recorded Recall result remains
readable as part of the current Task without another read of its source Task. Opening that source Task itself requires
permission for the source Task.
Records can arrive late, be incomplete or expire. Not available is not evidence that a message or action never existed. Bounded content pages let you continue reading retained content; they do not extend its retention. The Privacy notice owns retention and deletion limits.
The Task view’s Effects are Duale AI estimates, separate from the Tool’s recorded outcome. They do not verify a business change or provide an authorization decision. Read Effects and their evidence explains the distinction.
What you can query, and what you cannot
The Dashboard queries records by tenant, action, resource type, resource identifier, and time range. One page contains 100 records by default and at most 1,000. An export contains at most 100,000 records and uses JSONL or CSV.
There is no filter by acting person and no free-text search. A request for every event concerning one person cannot be answered through this query interface. If these records concern an identifiable person and your obligations include data-subject requests, plan that procedure around this limit.
Reads of the audit log are themselves recorded.
Audit operations use the Tenant-scoped resource audit:<tenant_id>. Querying records requires
audit:read_events, exporting them requires audit:export_events, and requesting a proof requires
audit:read_proof.
With the supplied human tiers, an Administrator can query and export records and request proofs. A Viewer can query records and request proofs but cannot export them. An Editor has no audit access.
You can verify record content, not append-only anchoring
When you request a proof for one event in the Dashboard, your browser checks the hash and shows the result. To check
records yourself, export them: each export row carries the exact canonical_event_data text and its content_hash.
Compute SHA-512 over the UTF-8 bytes of canonical_event_data, without parsing or reformatting it, and compare the
lowercase hexadecimal result with content_hash.
A match proves that the exact returned canonical text produces the returned stored hash. It detects a change to that text unless the hash changes with it.
The canonical text omits user_context, which can describe a person or Agent Identity together with request context,
or carry the exceptional audit-only system origin of a supplied-policy change. It never makes a service a Tenant
actor. Duale AI encrypts that object separately, but this hash check does not cover it. A matching hash verifies
none of those actor or request-context fields. Identity defines these distinctions.
You cannot verify the append-only anchoring independently today. The interface returns transaction values but no inclusion path and no independently trusted root. Treat that anchoring as an internal integrity control. Do not present it to an auditor as independently verified tamper evidence.
Link a Platform failure to your own records
When a Platform failure needs support or reconciliation, store each request, trace, or span identifier it carries with the owning business record, and include the available identifiers in a support request. Errors and reliability defines how the SDK exposes them.
When a business record must correlate a Task with Platform evidence, store the Task identifier when you submit the Task, not only after a failure. It is the durable link between those records.
Assign owners and record the change lists fields for a material change record.
Retain customer-held evidence only for its owning purpose and period. Do not copy prompts, credentials, or unrelated personal data merely to fill a Platform audit gap.
Contractual notification, data-return, deletion, audit, and availability terms belong to the legal documents, not to this record inventory.
Return to Security to place these records in the lifecycle of one Task.